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ponent  that  failed  to  match  the  pro¬ 
gram  must  be  an  IF  statement  The 
Error-Pattern  slot  has  the  value 
(IF  .  WHILE):  this  indicates  that  a 
WHILE  statement  was  found  when  an 
IF  statement  was  expected  These  test 
conditions  are  both  met  in  the 
WHILE-for-IF  example  so  the  action 
part  of  the  rule  is  activated.  The  ac¬ 
ton  part  of  this  rule  consists  of  a  Bug 
sloe  the  filler  of  this  slot  is  a  descrip¬ 
tion  of  the  bug  associated  with  the 
plan  difference  The  bug  in  this 
case  is  a  WHILE-for-IF  confusion. 
PROUSTs  bug  analyses  of  student 
programs  consist  of  bug  descriptions 
such  as  this.  When  PROUST  presents 
its  findings  to  the  student  it  takes 
each  bug  description  and  generates 
an  English-language  translation  for  it 
and  if  appropriate  generates  data  il¬ 
lustrating  the  presence  of  the  bug. 

Test  Results 

PROUST  has  been  tested  on  large 
numbers  of  beginners’  programs  We 
assigned  a  class  of  novice  program¬ 
mers  the  Rainfall  Problem  (an  elabora¬ 
tion  of  the  Averaging  Problem),  which 
is  shown  in  figure  8a. 

We  modified  the  Pascal  compiler 
our  students  were  using  so  that  it 
would  save  copies  of  every  syntac¬ 
tically  correct  program  that  they  com¬ 
piled.  This  allowed  us  to  examine  not 
only  the  final  solution  the  students 
handed  in.  but  also  every  inter¬ 
mediate  version  of  their  program. 
Since  the  first  versions  are  likely  to  be 
the  buggiest.  this  let  us  test  PROUST 
under  the  most  difficult  conditions 
possible 

Figure  8b  shows  the  results  of  run¬ 
ning  PROUST  on  the  Rainfall  Problem. 
There  are  206  different  attempted 
solutions  to  the  Rainfall  Problem  in 
the  test  set  Of  these  PROUST  was 
able  to  derive  a  complete  understand¬ 
ing  of  79  percent  of  the  programs 
identifying  94  percent  of  the  bugs  a 
percentage  far  higher  than  people  are 
able  to  achieve  The  chart  also  in¬ 
dicates  that  6  percent  of  the  bugs 
were  not  recognized  and  55  were 
false  alarms  Bugs  are  counted  as  not 
recognized  if  they  are  either  misdiag- 

lamamm t 


Listing  2:  A  coma  implementation  of  the  Bad  Input  Test  plan. 

WHILE  va<-0  00 
BEGIN 

Wnt*in(  InvaM  d ten.  please  MrW  ); 

Raw*  Vet); 

END: 

IF  Vtt  <  >  99999  THEN 


WHILE-loMF 
Staamentype  IF 
Emx-Paoem  (IF  .  WHILE) 

Bug  (WHILE-tor-lF  Confcaon  (FoundStns  ,*MR«0 

(Hufln*  ■HtsoryNoO*'))) 


Figure  7:  The  WHILE-jbr-iF  bug  rule  invoked  By  PROUST  to  explain  the  plan 
difference  between  the  faulty  part  of  the  program  of  figure  1  and  the  coma 
implementation  of  this  part  in  listing  i. 
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WkiiB  a  Paecd  program  Ihd  wi  prampt  the  ueer  to  input  number*  from  the  tarmmd; 
each  input  stands  tor  the  amourt  of  raintdl  in  New  Heven  tor  a  day.  Not*  Sncerainidl 
carnet  be  nagahra  iha  program  mould  reject  negative  input.  Tbur  program  should 
compute  the  tatoang  eMMcs  from  this  daa 

1.  the  average  rairM  per  day 

2.  the  numpar  of  rainy  daye 

3.  the  number  ot  valid  Input!  (awdudog  any  mvWto  daa  that  might  have  Oeen  reed  in) 
4  the  madman  amount  of  ran  that  iai  on  any  one  day 

Tha  program  should  read  data  until  th#  user  typaa  99999;  thla  *  a  sentinel  valua  signal¬ 
ing  tha  and.  of  input.  Do  not  indude  tha  99999  in  the  caicuimona.  Assume  that  if  trie 
input  wlue  n  nonnegaPve  and  not  equal  to  99999,  then  it «  valid  input  daa. 
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total  number  of  programs: 

206 

Number  of  programs  wrth  bugs: 

183 

(89  percent) 

Ntenbar  of  programs  raedving  fuk  sn  slyest: 

iei 

(79  percert) 

totol  number  of  bug* 

570 

Bugs  racogniad  corradty: 

533 

(94  percent) 

Bugs  net  racogniad: 

29 

(Spercers) 

Fade  alarm* 

55 

Nurtbar  d  programs  receiving  parsa  analyse*: 

35 

(17  percert) 

Tbta  number  of  bug* 

191 

Bugs  recognized  oorradty: 

Tt 

(37  percent) 

Bugs  daaad  from  anatyslc 

70  ■ 

(37  percert 

Bugs  not  racogniad 

SO 

(26  percent) 

Fade  alarm* 

19 

Number  d  programa  PROUST  dtf  nd  anatya: 

9 

(4  percent) 

Figure  8:  (a)  The  Rainfall  Problem  was  assigned  to  a  doss  of  novice  programmers  to 
test  the  effectiveness  of  PROUST,  (k)  This  shows  the  results  of  running  PROUST  on 
the  Rainfall  Problem, 
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Since  PROUST  first 
generates  a  possible 
implementation  and 
then  matches  it 
against  the  program, 

it  is  performing _ 

analysis  by  synthesis. 

process  that  it  went  through  ir  select¬ 
ing  the  Sentinel-Process-Read-While 
plan.  It  first  substitutes  all  pattern 
variables  in  the  goal  expression  that 
have  bindings  Since  ?New  has  Val  as 
a  binding,  the  subgoal  expression 
becomes  (Input  Val).  PROUST  then 
retrieves  plans  from  the  plan  database 
that  implements  Input  One  such  plan 
is  the  REAO  PLAN,  which  employs  a 
Pascal  Read  statement  to  input  the 
value  This  plan  matches  the  Reed 
statements  in  the  program. 

This  example  shows  how  PROUST 
analyzes  programs  by  predicting  the 
plans  that  might  be  used  and  then 
testing  these  predictions  By  selecting 
from  a  range  of  different  plans  and 
subplans  for  each  goal  PROUST  is 
able  to  generate  a  variety  of  dfiferent 
ways  of  implementing  each  goal. 
Since  PROUST  first  generates  a  pos¬ 
sible  implementation  and  then 
matches  it  against  the  program,  it  is 
performing  analysis  by  synthesis  In 
general,  generating  plan  hypotheses 
and  matching  them  against  programs 
is  rather  more  complex  than  the 
scenario  presented  here:  for  more  in¬ 
formation.  see  reference  3. 

Identifying  Bugs 

When  the  Sentinel-Process-Read- 
WhHe  plan  was  matched  against  the 
program  in  figure  la.  the  plan 
matched  exactly.  Since  there  were  no 
match  errors  there  must  not  have 
been  any  bugs  in  that  particular  plan. 
It  is  frequently  the  case  however,  that 
none  of  the  plans  that  PROUST 


predicts  matches  the  program.  When 
this  happens  PROUST  must  look  for 
bugs  that  account  for  the  mismatches 
in  one  of  the  plans  in  this  section  we 
will  discuss  one  of  these  mismatches 
in  connection  with  the  WHILE-foHF 
example  in  figure  2a  and  show  how 
it  leads  to  the  discovery  of  a  bug. 

The  bug  In  the  WHILE-for-IF  exam¬ 
ple  is  discovered  in  processing  the 
Input-Validation  goal  One  of  the  plans 
that  PROUST  suggests  for  implement¬ 
ing  this  goal  is  the  socalled  Bad  In¬ 
put  Loop  lest  plan.  This  plan  consists 
of  a  WHILE  statement  that  tests  the 
input  to  see  if  it  is  out  of  range  an 
error  message  inside  the  WHILE  loop, 
an  Input  subgoal  that  rereads  the  in¬ 
put  if  it  is  out  of  range  and  a  test  to 
see  if  the  exit  condition  for  the  main 
loop  has  been  satisfied. 

Listing  2  illustrates  a  correct  imple¬ 
mentation  of  this  plan  (solving  the 
Averaging  Problem). 

The  Bad  Input  Loop  lest  plan 
matches  the  WHILE-for-IF  example  of 
figure  2a  In  all  but  one  respecc  there 
is  no  test  for  the  exit  condition  of  the 
main  loop  such  as  IF  Val  <  >  99999 
THEN  ....  Where  an  IF  statement 
is  expected,  a  WHILE  statement  ap¬ 
pears  instead  PROUST  has  thus  en¬ 
countered  a  plan  difference,  ie..  a  dif¬ 
ference  between  the  expected  plan 
and  the  code  When  PROUST  en¬ 
counters  plan  differences  it  does  not 
give  up  on  the  plan:  instead  It  tries 
to  find  a  way  of  interpreting  the  plan 
differences  as  bugs. 

in  most  cases  plan  differences  are 
explained  by  means  of  bug  rule.  Each 
bug  rule  has  a  test  part  which  ex¬ 
amines  the  plan  differences  to  see 
whether  the  rule  is  applicable  and  an 
action  part  which  explains  the  plan 
difference! 

Figure  7  show's  the  bug  rule  that  is 
invoked  to  explain  the  plan  dif¬ 
ferences  in  the  WHILE-for-IF  example 
The  rule  is  written  in  slot-filler  nota¬ 
tion:  one  set  of  slots  constitutes  the 
test  part  of  the  rule  and  another  set 
constitutes  the  action  part  In  the 
WHILE-for-IF  rule  the  test  part  con¬ 
sists  of  a  Statement-Type  slot  and  an 
Error-Pattern  slot  The  Statement- 
Type  slot  indicates  that  the  plan  com- 
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PROUST  substitutes 
any  objects  whose 
values  are  already 
known  into  the 
goal  expression. 


objects  whose  values  are  already 
known  into  the  goal  expression.  At 
this  point  the  only  information  avail¬ 
able  about  TNew  and  TSentinei  is 
what  appears  in  the  problem  descrip¬ 
tion.  There  the  value  of  TSentinei  is 
listed  as  99999  but  the  value  of  TNew 
is  not  listed.  Therefore  the  value  of 
?Sentinel  is  substituted  into  the  goal 
expression,  but  TNew  is  left  un¬ 
changed.  The  resulting  goal  expres¬ 
sion  is  (Sentinei-Controlted-Input 
?New  99999). 

PROUST  must  now  retrieve  from  its 
programming  knowledge  base  plans 
that  could  be  used  to  implement  the 
goal  Sentinet-Controlled-Input  It 
retrieves  the  filler  of  the  Instances  slot 
of  the  definition  of  Sentinel-Con- 
trolled-lnput  shown  in  figure  4.  This 


filler  is  a  list  of  five  items:  Sentinel- 
Process-flead-While  Sentinel-Read- 
Process-While  Sentinel-Read- 
Process-Repeat  Sentinel-Process- 
Read-Repeat  and  Bogus-Counter- 
ControUed-Loop  Each  of  these  is  the 
name  of  a  plan.  PROUST  selects  the 
first  plan  from  the  list  Sentinel- 
Process-ReadWhile  This  will  be 
PROUSTs  initial  hypothesis  of  how 
the  program  implements  the  goal 
Sentinel-ContFoiled-lnput 
lust  as  known  values  of  objects  were 
substituted  into  the  goal  expression 
(Sentinel-Controlled-Input  ?New 
TSentinei).  these  same  substitutions 
must  now  be  performed  on  the 
selected  plan,  lb  see  what  substitu¬ 
tions  must  be  made  PROUST  ex¬ 
amines  the  Pom  skx  of  the  definition 
of  Sertnei-CortroliecWnput  (Sentinel- 
Controlled-Input  Tlnput  TStop).  The 
Form  dot  indicates  which  pattern-vari¬ 
able  names  are  used  in  the  plans  that 
implement  the  goal.  By  comparing 
the  Form  slot  to  the  goal  being 
analyzed.  PROUST  determines  that 
each  occurrence  of  Tlnput  in  die 
selected  plan  should  be  replaced  by 
the  value  of  TNew  Each  occurrence 
of  TStop  should  be  replaced  by  the 
value  of  TSentinel  or  99999.  Because 
the  value  of  TNew  is  not  known. 


SudWt  program 

Wn tam(  Entar  value' ); 
PmeK  v« ); 

WHILE  V«|<  >99999  00 
BEQin  « 

WHILE  VN<  -0  00 
BEGIN 


READ  PLAN 
(RaadVal) 

/  f  TNaw  -  ve 


((SUBGOAL  (Input  Tlnput)) 

-  (WHILE  (<  >  Tlnput  99999) 

-  .  (BEGIN 

.  r 

(SUBGOAL  (input  ?lnput))») 


Raw*  VN); 

SNO; 

Sum  :■  Sum  ♦  Vat 
Count  :*  Counts  1; 
Wnwm(  Entar  value'  y 
PmO.  val);—, 

END: 


TNaw  -  V* 


REAP  PLAN 
'•(RaadVal) 


Figure  6:  Tfcu  shows  how  the  Sentinel-Process-Read-While  plan  is  matched 
against  the  program  in  figure  I. 

i a*  BYTE-  apwl  iaai 


PROUST  simply  replaces  Tlnput  with 
the  variable  name  TNew  PROUST 
assumes  that  the  process  of  match¬ 
ing  the  plan  against  the  program  will 
determine  what  the  value  of  TNew  is. 

Figure  6  shows  how  the  Sentinel- 
Process-Read-While  plan  is  matched 
against  the  program  example  in  figure 
la.  Matching  starts  with  the  WHILE 
loop.  The  pattern  in  the  plan  for  the 
WHILE  loop  ir (WHILE  (<  >  TNew 
99999)  . . .).  There  are  two  WHILE 
loops  in  this  program:  WHILE  Val 

<  >  99999  DO  ...  and  WHILE  Val 

<  ■  0  DO  ....  PROUST  tries  to 
match  each  pattern  against  each  of 
these  statements.  (WHILE  (<> 
TNew  99999)  . . .)  matches  WHILE 

Vai  <  >  99999  DO  _ provided 

that  Vai  is  subsumed  for  TNew. 
(WHILE  (<>  TNew  99999)  . .  .) 
does  not  match  WHILE  Val  <  ■  0  DO 
. . .  because  the  statement  has  a  <• 
test  instead  of  a  <>  test  and 
because  it  tests  against  0  instead  of 
99999  Therefore  PROUST  selects 
WHILE  Vai  <  >  99999  DO  ...  as 
the  match  for  die  plan  pattern.  Since 
Vai  must  be  substituted  for  TNew  so 
that  the  pattern  matches.  Val  is 
recorded  as  the  binding  for  TNew 
Afterward,  any  component  of  the  plan 
that  has  TNew  in  it  will  have  Val  sub¬ 
stituted  for  TNew. 

The  next  plan  component  that 
PROUST  matches  against  the  program 
is  (BEGIN  . . . ).  There  are  several  dif¬ 
ferent  BEGIN  statements  in  the  pro¬ 
gram  that  could  be  matched  against 
this  pattern.  However,  in  the  plan  tem¬ 
plate  the  (BEGIN  . . .)  pattern  ap¬ 
pears  inside  of  the  WHILE  pattern 
that  was  just  matched  This  means 
that  the  BEGIN  statement  that  this 
pattern  matches  must  be  located  in¬ 
side  of  the  WHILE  Val  <  >  99999 
DO  . . .  statement  Therefore  there 
is  only  one  BEGIN  statement  that  has 
an  appropriate  match. 

When  PROUST  tries  to  match  the 
(SUBGOAL  (Input  TNew))  com¬ 
ponents.  a  different  type  of  process¬ 
ing  is  required.  These  plan  com¬ 
ponents  are  goals:  to  match  them 
against  the  program.  PROUST  must 
go  through  the  same  plan-selection 
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problem  descriptions  Plans  are 
stereotypic  methods  for  implement¬ 
ing  goals  A  large  part  of  writing  pro¬ 
grams  consists  of  identifying  goals 
that  must  be  satisfied  and  selecting 
plans  to  implement  these  goals 
Similarly.  PROUST  retrieves  plans 
from  its  knowledge  base  for  each  goal 
referred  to  in  the  problem  descrip¬ 
tion.  it  compares  these  plans  to  the 
student  s  program  to  determine  which 
fits  the  program  best. 

Figure  4  shows  PROUSTs  definition 
for  the  Sentinel-ContiollecHnput  goaL 
The  goal  definition  contains  a  series 
of  sloes;  InstancaOf.  Form.  MainSeg- 
merit  etc.  together  with  fillers  for 
each  of  these  slots:  Read&Procese 


Main  Loop:.  ?New.  etc  These  slots 
serve  various  functions  only  some  of 
which  weevil!  discuss  here  The  most 
important  slots  are  the  Instances  and 
InstancaOf  slots.  The  Instances  slot 
lists  the  various  plans  in  PROUSTs 
knowledge  base  for  implementing  this 
goaL  This  slots  filler  is  a  list  of  five 
items  each  of  which  is  the  name  of 
a  plan.  The  InstancaOf  slot  indicates 
the  dass  to  which  this  goal  belongs 
The  goal  class  in  this  case  is  Read& 
Process  which  is  the  dass  of  all  goals 
that  involve  reading  a  sequence  of 
values  and  processing  them. 

Figure  5  shows  a  plan,  the  Sentinel- 
Process-Read-While  plan.  This  is  one 
of  the  instances  erf  the  Sentinei- 


Controiled-lnput  goal.  This  plan  is  a 
simplified  version  of  the  one  PROUST 
actually  uses  Plans  are  also  defined 
in  terms  of  slots  and  fillers  The  most 
important  slot  is  the  Template  sloe 
which  describes  the  form  the  Pascal 
code  implementing  this  plan  should 
take.  Plan  templates  consist  of  Pascal 
statements  subgoals  and  labels  The 
Pascal  statements  are  written  in  list 
notation  rather  than  ordinary  Pascal 
syntax;  for  example  the  form  (WHILE 
(  <  >  Ttnput  TStop)  . .)  in  Pascal 
syntax  would  appear  as  WHILE  Tin- 
put  <  >  TStop  DO  . .  Symbols 
that  are  preceded  by  question  marks 
are  pattern  variables:  these  are  sub¬ 
stituted  when  the  plan  is  used.  TNew 
is  substituted  by  a  Pascal  variable  con¬ 
taining  the  input  data,  and  TStop  is 
substituted  by  a  constant  the  sentinel 
value  The  T*  statement  is  a  "wild 
card"  pattern  that  can  be  substituted 
by  an  arbitrary  sequence  of  Pascal 
statements:  this  is  just  a  placeholder 
in  the  plan.  Subgoals  are  indicated  by 
(SUBGOAL  . . .)  forms  in  the  tem¬ 
plate  these  are  goals  that  must  in  turn 
be  implemented  using  ocher  plans. 

Matching  Plans 

Lets  look  at  how  plans  and  goals  are 
used  to  understand  a  program.  The 
plan  in  listing  1  has  been  imple¬ 
mented  correctly.  Ybu  will  see  how 
PROUST  hypothesizes  a  plan  that  the 
program  might  use  and  then  matches 
this  plan  against  the  program.  In  this 
case  the  match  succeeds  because  the 
plan  is  implemented  correctly.  In  the 
next  section  we  will  examine  what 
happens  when  plans  fail  to  match 
because  the  students  code  has  bugs. 

The  first  step,  before  any  analysis  of 
goals  and  plans  takes  place  is  to 
parse  the  students  Pascal  program. 
This  results  in  a  parse  tree  All  subse¬ 
quent  analysis  of  the  program  is  per¬ 
formed  on  the  parse  tree  rather  than 
on  the  original  program  text 

When  PROUST  analyzes  a  program, 
it  selects  goals  from  the  problem 
description  one  at  a  time  Lets  sup¬ 
pose  that  the  goal  that  is  selected  first 
is  (Sentinel-Controlled-Input  TNew 
TSentinel).  PROUST  substitutes  any 
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Figure  3:  The  Avenging  Problem  translated  into  PROUSTs  problem-description 
language 
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PROUST 


mon  bugs  to  see  if  it  can  explain  the 
discrepancies. 

PROUSTs  Problem 
Descriptions 

Problem  descriptions  in  PROUST  con¬ 
sist  of  programming  goals  and  sets  of 
data  objects.  Programming  goals  are 
the  principal  requirements  that  must 
be  satisfied:  sets  of  data  objects  are 
the  data  that  the  program  must 
manipulate 

The  first  step  in  translating  an 
English-language  problem  statement 
into  PROUSTs  problem-description 
language  is  to  make  die  various  goals 
that  are  mentioned  in  the  problem 
statement  explicit  Recall  that  the  text 
of  the  Averaging  Problem  is  the 
following: 

Wide  a  program  that  reads  in  a  se¬ 
quence  of  positive  numbers,  stop¬ 
ping  when  99999  is  read  Compute 
the  average  of  these  numbers.  Do 
not  include  the  99999  in  the 
average  Be  sure  to  reject  any  in¬ 
put  that  is  not  positive 

Solutions  to  this  problem  operate  on 
a  sequence  of  input  data:  let  us  call 
this  sequence  New.  The  following 
goals  can  be  extracted  from  the  prob¬ 
lem  statement 

•  Read  successive  values  of  New. 
stopping  when  a  sentinel  value 
999991  is  read. 

•  Make  sure  that.the  condition  New 
<  ■  0  is  never  true 

•  Compute  the  average  of  New 

•  Output  the  average  of  New 

Ufe  must  now  take  these  goals  and 
use  them  to  generate  a  problem 
description  for  PROUST.  Each  data 
object  that  the  goals  refer  to  is  named 
and  declared  Each  goal  extracted 
from  the  problem  statement  is  re¬ 
corded  in  the  problem  description. 
The  resulting  problem  description  is 
shown  in  figure  1. 

Like  ail  the  data  structures  that  we 
discuss  in  this  article  problem 
descriptions  are  in  list  notation  and 
every  statement  and  expression  is 
enclosed  in  parentheses  The  name  of 
the  program  is  indicated  with  a 
Define-Program  statement  Objects 


Listing  1:  Yd  another  m/  to 
ilhpkment  the  input  validation  for  the 
A temping  Proton. 

mat  'ft  v 
WHILE  VW<-0  00 
BEGIN 

WnWn(  invaftd  Wtry,  rmnot ); 
Raw*  vg ); 

END. 

WHILE  ve<  >99999  00 
BEGIN 

Sum  :■  Sum+Vrt 
Count :«  Count+1; 
wntwy  Emw  vWu*' ); 

Raw*  VN); 

WHILE  VM<-ODO 
BEGIN 

WrMn(  invalid  wiry,  raartar' ); 
Raw*  VM); 

END; 

END; 


are  named  using  DefineObject  state¬ 
ments  Goals  are  indicated  using 
Define-Goal  statements 
Object  names  are  preceded  by 
question  marks  There  are  two  objects 
defined  in  the  Averaging  Problem 
description.  TSentinef  and  ?New  The 
question-mark  notation  is  used  fre¬ 
quently  in  artificial-intelligence  (AI) 
programs;  it  indicates  that  the  vari¬ 
able  is  not  a  literal  value  but  is  a 
parameter  that  must  be  substituted 
when  the  data  structure  is  used.  For 
example  the  input-data  object  '’New 
will  be  substituted  with  the  name  of 
the  Pascal  variable  that  the  student 
uses  for  storing  the  input  data.  The 
object  TSenbnel  has  the  value  99999: 
wherever  ?Sentinei  appears  in  the 
problem  description  It  can  be  sub¬ 
stituted  with  99999i 
Objects  can  be  either  constant¬ 
valued  or  variable-valued  In  this  ex¬ 
ample  TSentinel  is  a  constant  with 
the  value  999991  and  ?New  is  a 
variable  In  PROUSTs  general  prob¬ 
lem-description  language  objects  can 
have  a  variety  of  properties  asso¬ 
ciated  with  them:  however,  we  will  not 
use  any  such  properties  in  this  sim¬ 
ple  example 


Goal  statements  consist  of  a  name 
of  ajype  of  goal,  followed  by  a  list  of 
arguments,  in  the  form  (Average 
?New)  for  example  Average  is  a  type 
of  goal  (to  compute  an  average),  and 
?New  is  the  argument  of  the  goal. 
This  form  requires  that  the  program 
compute  the  average  of  ?Nsw 
Arguments  to  goal  expressions  can 
take  a  variety  of  forms.  They  can  be 
objects,  predicates  or  even  other  goal 
expressions  In  the  expression  (Input- 
Validation  ?New  (<  m  ?New  0)).  one 
argument  is  an  object  (?New).  and  the 
other  is  a  predicate  ?New  <■  Q  In 
LISP,  function  names  and  operators 
precede  their  arguments  which  is  why 
the  <  ■  precedes  the  ?New  and  0  in 
the  expression  (<•  0 ).  If  goals  are 
nested  as  in  (Output  (Average 
?New)).  the  outer  goal  refers  to  die 
value  computed  by  die  inner  goal. 
Thus  this  goal  requires  that  the  pro¬ 
gram  output  the  average  of  ?New 
In  this  example  PROUSTs  problem 
descriptions  are  a  reasonable  approx¬ 
imation  of  the  original  English-lan¬ 
guage  problem  statements  These 
problem  descriptions  describe  what 
the  programs  must  do  but  not  how 
they  are  supposed  to  do  it  PROUST 
must  analyze  each  individual  program 
and  determine  how  it  is  intended  to 
satisfy  the  problem  requirements 

Programming  Knowledge 

Programming  knowledge  in  PROUST 
is  frame-based  (see  reference  5).  In 
frame-based  systems  knowledge  is 
organized  into  frames  each  of  which 
corresponds  to  a  particular  concept 
that  the  system  "knows"  about 
Frames  are  similar  to  records  in  rela¬ 
tional  databases  although  the  opera¬ 
tions  that  can  be  performed  on 
frames  are  somewhat  different. 
Knowledge  in  frames  is  organized  into 
slots  which  function  as  record  field 
names  and  fillers  which  are  the 
values  assigned  to  each  slot 
The  two  kinds  of  programming 
knowledge  that  we  will  consider  here 
are  goals  and  plans  (ocher  types  of 
programming  knowledge  are  dis¬ 
cussed  in  reference  6).  Goals  are 
problem  requirements  that  appear  in 

imwiwid) 


apkil  iwi  •  am  it* 


Data-flow  analysis  checks  for  clear 
anomalies  in  the  pattern  of  data 
definition  and  for  use  of  data  in  a  pro¬ 
gram.  It  can  determine  when  a  vari¬ 
able  is  defined  and  never  used  or 
when  a  variable  is  never  defined 
However,  if  there  are  no  anomalies  in 
data  flow,  data-flow  analysis  will  not 
detect  any  bugs  Neither  example  in 
the  preceding  section  has  data-flow 
anomalies  so  this  method  would  not 
detea  the  bugs 

Ybu  might  also  try  analyzing  the 
structure  of  the  program  itself  to  see 
whether  it  suggests  the  presence  of 
bugs  Ybu  could  build  a  library  of 
templates  for  common  bugs  such  as 
missing  sentinel  tests  or  WHILE 
statements  in  place  of  IF  statements 
and  then  match  these  templates 
against  the  program  to  identify  the 
bugs  The  problem  with  this  approach 
is  that  you  have  no  way  of  knowing 
where  to  match  the  bug  templates  in 
the  program.  For  example  the 
WHILE-for-IF  example  has  three  dif- 
.erent  WHILE  loops  How  could  you 
tell  which  WHILE  loop  really  should 
be  an  IF  statement  or  if  any  of  them 
should  be  an  IF  statement?  Ybu  could 
try  to  make  the  bug  template  more 
specific  by  making  it  apply  only  when 
there  are  two  loops  with  the  same  exit 
test  one  inside  the  other.  But  that 
would  make  the  template  too  specific 
it  would  not  apply  to  other  cases 
where  WHILE  statements  appear  in¬ 
stead  of  IF  statements 

All  of  these  approaches  to  debug¬ 
ging  attempt  to  identify  bugs  without 
any  understanding  of  what  die  pro¬ 
gram  is  supposed  to  da  and  arty  such 
approach  does  little  more  than  make 
guesses  as  to  what  bug  is  involved  in 
order  to  do  better,  a  debugging  sys¬ 
tem  has  to  be  able  to  infer  the  pro¬ 
grammer's  intentions  and  relate  them 
to  the  code 

PROUSTs  Approach 

PROUST  is  written  in  T.  a  dialect  of 
LISP  The  full  system  contains  roughly 
1 5.000  lines  of  LISP  code  and  runs  on 
a  VAX-1 1/750.  A  stripped-down  ver¬ 
sion  called  Mlcro-PROUST  has  been 
developed  in  conjunction  with 
Courseware  Inc.  of  San  Diego  Califor- 


PROUST 


Micro- 
PROUST  for 
THE  IBM  PC 

Micro-PROUST  is  a  subset  of  the 
larger  implementation  of 
PROUST  It  is  capable  of  dealing  with 
a  limited  range  of  nonce  programs  and 
is  currently  set  up  to  handle  only  those 
example  solutions  to  the  Averaging 
and  RamfeO  Problems  provided  with  it 
Micro-PROUST  runs  in  Cold  Hill  Com¬ 
puters  Inc  Golden  Common  USP  on 
an  IBM  Personal  Computer  with  5I2K 
bytes  of  memory  The  source  code  and 
example  programs  are  available  for 
downloading  from  BYTEner  Listings. 
The  telephone  number  is  (603) 
924-9820.  The  file  PRSTREAQME  con¬ 
tains  directions  on  how  to  run  Micro- 
PROUST. 


nia  (see  the  text  box  "Micro-PROUST 
for  the  IBM  PC  above  for  more  infor¬ 
mation).  Micro-PROUST  is  capable  of 
recognizing  the  kinds  of  bugs  that  are 
described  in  this  article;  however, 
there  are  a  variety  of  tricky  bugs  that 
PROUST  can  identify  but  Micro- 
PROUST  cannot  (If  you  are  interested 
in  PROUSTs  full  diagnostic  capabili¬ 
ties.  consult  reference  3.) 

PROUSTs  analysis  of  programs  is 
based  on  knowledge  of  the  program¬ 
ming  problem.  Students  may  solve 
the  problem  in  a  variety  of  ways  and 
their  programs  may  have  a  variety  of 
bugs,  but  they  are  aO  trying  to  solve 
the  same  problem.  Knowledge  of  the 
problem  makes  the  variability  of 
novice  solutions  more  manageable  It 
also  provides  important  information 
about  the  programmer's  intentions 
%  provide  PROUST  with  descrip¬ 
tions  of  the  programming  problems 
we  devised  a  problem-description 
language  We  described  each  problem 
in  this  language  and  provided 
PROUST  with  a  library  of  the  descrip¬ 
tions  Each  problem  description  in 
PROUSTs  problem-description  lan¬ 
guage  is  a  paraphrase  of  the  English- 
language  problem  statement  that  we 


hand  out  to  students 

Tb  understand  the  students'  pro¬ 
grams  PROUST  also  needs  to  know 
how  to  solve  the  problem.  Solutions 
to  a  given  programming  problem  may 
be  implemented  in  a  variety  of  dif¬ 
ferent  ways  Suppose  that  there  was 
only  one  way  to  test  input  for  validity 
in  a  Pascal  program,  namely,  to  insert 
a  WHILE  loop  at  the  top  of  the  main 
loop,  such  as  in  figures  la  and  2a. 
Once  PROUST  knew  that  a  program 
must  validate  input  it  would  know  to 
look  for  such  a  loop,  as  well  as  for  the 
sentinel  test  that  must  follow.  How¬ 
ever.  there  are  several  ways  of 
validating  input  Listing  l  shows  a 
loop  that  tests  input  in  a  different  way. 
Instead  of  there  being  one  input 
validation  loop,  there  are  two;  one  is 
at  the  bottom  of  the  loop  and  the 
other  precedes  the  loop.  No  addi¬ 
tional  sentinel  test  is  required  when 
this  method  is  used,  because  as  soon 
as  input  is  validated,  control  flows  to 
the  main  exit  test  of  the  WHILE  loop. 
Therefore  without  knowing  what 
method  the  programmer  is  using  for 
validating  input  PROUST  cannot  tell 
whether  to  look  for  a  sentinel  test 
within  the  body  of  the  loop.  In  figure 
la  it  is  an  error  not  to  have  such  a  sen¬ 
tinel  test  but  in  listing  I  it  is  not 
PROUST  needs  knowledge  about  pro¬ 
gramming  so  that  it  can  understand 
haw  each  student  designed  and  im¬ 
plemented  his  or  her  solution.  Once 
it  understands  the  programmer  s  in¬ 
tentions.  it  can  then  use  knowledge 
about  common  bugs  to  identify  them 
in  the  student's  program. 

PROUST  analyzes  programs  by  syn¬ 
thesis.  When  PROUST  examines  a 
program,  it  looks  up  the  correspond¬ 
ing  problem  description  in  its  library. 
It  makes  hypotheses  about  the 
methods  programmers  may  use  to 
satisfy  each  requirement  in  the  prob¬ 
lem  description.  Each  hypothesis  is  a 
possible  correa  implementation  of 
the  corresponding  requirement  If 
one  of  these  hypotheses  fits  the  stu¬ 
dent's  code  then  PROUST  infers  that 
the  requirement  is  implemented  cor¬ 
rectly.  If  PROUSTs  hypotheses  do  not 
fit  the  student's  program,  then 
PROUST  checks  its  database  of  com- 
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merits  and  does  not  understand  how 
the  control  flow  in  a  WHILE  loop 
works.  As  long  as  the  body  of  the 
loop  is  sraight-line  code  the  student 
has  no  problem.  However.  If  the  body 
of  the  loop  contains  tests,  the  student 
thinks  that  die  tests  should  be  written 
as  WHILE  statements  to  ensure  that 
they  repeat  when  the  body  of  the 
loop  does.  \Me  will  refer  to  this  mis¬ 
conception  henceforth  as  the  WHILE- 
for-iF  misconception.  PROUSTs  out¬ 
put  for  this  example  shewn  in  figure 
2  b.  takes  the  misconception  into  ac¬ 
count  and  explains  it  to  the  student. 

The  bugs  in  figures  la  and  2a  illus¬ 
trate  the  following  points.  First  bugs 
frequently  cannot  be  detected  if  you 
don't  know  what  the  program  is  sup¬ 
posed  to  da  Both  of  the  programs 
shown  run  no  matter  what  input  is 
read:  to  determine  that  there  Is  a  bug. 
you  must  recognize  that  the  programs 
output  different  results  than  they 
should.  Bugs  such  as  these  are  not 
unusual:  the  missing  sentineHest  bug 
occurs  in  18  percent  of  novice  pro¬ 
grammers'  solutions  to  the  Averaging 
Problem. 

Second,  novice  programmers  need 
help  identifying  such  bugs  These 
bugs  cause  the  programs  to  fail  only 
after  unusual  inputs-ones  that  novice 
programmers  are  unlikely  to  test,  in 
the  case  of  the  WHILE-for-IF  miscon¬ 
ception,  even  if  the  programmer  tests 
the  case  in  question,  he  or  she  will 
probably  not  understand  why  the  pro¬ 
gram  fails  because  he  or  she  expects 
the  WHILE  statement  to  perform  a 
different  function  than  it  actually 
does. 

Alternatives  to 
Intention-based  Debugging 
lb  support  our  claim  that  debugging 
requires  knowledge  of  the  program¬ 
mers  intentions,  we  will  examine  the 
principal  alternatives  to  infention- 
based  debugging  and  show  why  they 
fall  short.  The  methods  we  have  con¬ 
sidered  are  analysis  of  I/O  (Input/out¬ 
put)  behavior,  analysis  of  data  flow, 
and  recognition  of  patterns  of  buggy 
code 

Debugging  by  analyzing  I/O  be¬ 
havior  involves  determining  when  the 
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WHILE  VW<  .0  00 
BEGIN 

WrMn(  VtraMorary. 


END: 

WHILE  VM<  >98888  DO 
BEGIN 

Sum  :■  Sun+VW, 
Count  :m  Court*  1; 
WiMnf  Era*  mAw’  y, 
RmkZVW  ). 

END. 

END. 

IP  Court  -  0  twi 

mJ  OH  Wmmwu  ) 

ELSE  BEGIN 
Avg  :■  SunVCourt 

WePni  IfiQ  )i 

END: 

END 


PROUST*  output 

You  Ira  u*ng  ■  WHILE  *N*n*ra  *  few  IS  whm  you  Would  have 
■**oi*l  You  probably  want  tha  coda  Halting  *  tna  15  to  axacuw 
WtN  through  the  loop;  your  oode  make  K  axacuw  many  wras. 

Tha  awnant  in  quatfon  •: 

WHILE  Valo 98899  00  ... 


Figure  2:  (a)  Another  navi a  pngmn net's  attempt  et  implementing  the  Averaging 
Problem.  (6)  PROUST  once  again  explains  what  the  problem  with  the  program  is.  what 
the  programmer  wanted  to  do.  and  what  he  actually  did. 


uead  an  IF 
once  each 


output  of  the  program  is  incorea  and 
suggesting  bugs  that  might  have 
caused  the  faulty  behavior  (see  refer¬ 
ence  2).  This  approach  treats  debug¬ 
ging  as  similar  to  medical  diagnosis 
(see  reference  4).  The  faulty  behavior 
can  be  thought  of  as  the  symptoms 
of  the  program,  and  the  bugs  can  be 
thought  of  as  the  diseases.  There  are 
two  problems  with  this  approach:  A 
program's  symptoms  cannot  always 
be  determined  and  these  symptoms 
cannot  always  be  related  to  the  bugs. 
The  bugs  in  the  programs  in  figures 
la  and  2a  affect  the  output  of  the  pro¬ 
gram  only  occasionally;  recognizing 


when  this  happens  requires  knowl¬ 
edge  about  what  the  output  should 
look  like  Since  the  WHILE-for-iF  ex¬ 
ample  fails  to  test  the  input  for  validi¬ 
ty  after  the  first  positive  value  is  read 
it  appears  that  this  program  is  miss¬ 
ing  an  input-validation  test.  It  is  only 
after  inspecting  the  code  that  it 
becomes  dear  that  the  bug  is  not  in 
the  input-validation  test  but  in  the  sen¬ 
tinel  test 

Another  debugging  approach  you 
might  try  is  data-flow  analysis  (see 
reference  I).  This  is  the  approach 
many  error-checking  compilers  use 
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grammer's  intentions  assists  debug¬ 
ging.  we  will  present  two  examples  of 
"buggy"  programs  and  discuss  why 
alternative  approaches  to  automatic 
debugging  fail  to  identify  such  bugs 
Then  we  will  describe  how  PROUST 
analyzes  such  programs  Finally,  we 
will  present  some  statistics  showing 
PROUSTs  performance  on  large 
numbers  of  students'  solutions  to  a 
typical  assignment  in  an  introductory 
programming  class  This  will  help  sup¬ 
port  our  claim  that  PROUSTs  ap¬ 
proach  is  adequate  for  the  maiority 
of  novice  programmers  programs 

Examples  of  Program  Bugs 
Here  is  a  simple  programming  prob¬ 
lem  called  the  Averaging  Problem: 


Vfrite  a  program  that  reads  in  a  se¬ 
quence  of  positive  numbers  stop¬ 
ping  when  99999  is  read.  Compute 
the  average  of  these  numbers  Do 
not  include  the  99999  in  the  aver¬ 
age.  Be  sure  to  reject  any  input  that 
is  not  positive 

The  student's  program  must  compute 
the  average  of  a  series  of  positive 
numbers  It  must  ensure  that  the  in¬ 
put  to  the  program  is  in  fact  positive 
The  input  terminates  when  a  specific 
value— 99999— is  read  values  such  as 
this  which  signal  the  end  of  input  are 
called  sent inei  values. 

Figure  la  shows  a  sample  solution 
to  the  Averaging  Problem.  This  pro¬ 
gram  works  except  for  the  following 


Figure  1:  (a)  One  novice  programmers  attempt  at  implementing  the  hemaging 
Pnbiem  (6|  PROUST  apiains  the  bug  lurfrinf  in  the  program  In  concise  English 
sentences  and  even  offers  data  illustrating  the  error. 


bug:  if  you  type  99999  immediately 
after  typing  a  nonpositive  value  the 
program  will  continue  to  prompt  far 
data  after  the  99999  is  read.  When 
the  program  finally  does  terminate 
the  average  will  be  incorrect  For  ex¬ 
ample  suppose  that  you  input  5,-5, 
99999.  instead  of  terminating  when 
the  99999  is  read,  the  program  re¬ 
quests  another  input  If  the  user  then 
entered  another  99999  the  program 
would  not  print  the  average  as  5.  but 
instead  would  print  (5+99999V2.  or 
50002. 

The  program  interprets  99999  as 
data  when  the  sequence  5.  -5, 
99999  is  read  because  when  the  pro¬ 
gram  reads  the  -5  it  enters  the  input- 
validation  loop,  which  starts  with  line 
10.  WHILE  Vial  <-  0  DQ  This  loop 
is  intended  to  iterate  until  a  positive 
value  is  typed  in:  99999  is  positive 
so  when  the  99999  is  read,  control 
leaves  the  input-validation  loop.  How¬ 
ever,  the  program  was  written  with  the 
assumption  that  when  the  input- 
validation  loop  is  exited  the  current 
value  of  Vai  is  valid  input  data.  In  this 
case  \tal  is  not  valid  data:  it  is  99999. 
the  sentinel  value  The  loop  never¬ 
theless  processes  99999  as  if  it  were 
data,  lb  guard  against  this  case  there 
should  be  a  test  for  the  sentinel  after 
the  input-validation  loop. 

Figure  lb  is  PROUSTs  output  de¬ 
scribing  the  missing  sentinel-test  bug. 
The  error  is  described  in  two  ways: 
First  it  is  described  in  English:  then 
PROUST  generates  an  example  erf 
data  that  causes  the  program  to  fail. 

Now  look  at  the  program  in  figure 
2a.  This  is  another  solution  to  the 
Averaging  Problem,  and  the  bug  in 
this  program  is  also  fairly  obscure.  If 
you  type  a  positive  value  followed  by 
a  negative  value  the  negative  value 
will  be  included  in  the  average  Thus 
if  you  type  -2. 2. 99999.  the  average 
will  be  2.  but  if  you  type  2.  -2. 
99999.  the  average  will  be  0. 

Unlike  the  example  in  listing  la.  the 
programmer  has  not  left  out  the  sen¬ 
tinel  test  but  has  written  the  test  in  the 
form  of  a  WHILE  statement  instead 
of  an  IF  statement.  The  student  prob¬ 
ably  has  a  misconception  about  the 
distinction  between  the  two  state- 
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PROUST 


by  W.  Lewis  Johnson  and  Elliot  Soloway 

An  automatic  debugger 
for  Pascal  programs 


J  PROUST  (Program  Understander  for 
Students)  is  a  knowledge-based  sys¬ 
tem  that  finds  nonsyntactic  bugs  in 
Pascal  programs  written  by  novice 
programmers.  When  students  com¬ 
pile  a  program  successfully.  PROUST 
is  automatically  invoked  to  analyze  it. 
PROUST  reports  any  bugs  that  are  tn 
the  program  to  the  student 

PROUST  is  net  merely  a  tool  that 
helps  programmers  find  bugs,  nor  is 
it  confined  to  a  narrow  class  of  bugs, 
such  as  uninitialized  variables.  It  is 
designed  to  find  every  bug  in  most 
beginners'  programs.  PROUST  is  cur¬ 
rently  capable  of  coneedy  identifying 
all  of  the  bugs  in  over  70  percent  of 
the  programs  that  students  write 
when  we  assign  them  moderately 
complex  programming  problems. 
When  PROUST  finds  a  bug.  It  does 
not  simply  point  to  the  lines  of  code 
that  are  among:  instead,  it  determines 
how  the  bug  can  be  corrected  and 
suggests  why  the  bug  arose  In  the  first 
plan.  Our  aim  is  to  build  an  instruc¬ 
tional  system  around  PROUST  that 
assigns  programming  problems  to 
students,  reads  their  work,  and  gives 
them  helpful  suggestions. 

In  designing  PROUST  we  found  it 
necessary  to  deal  directly  with  the 


variability  of  bugs  in  beginners'  pro¬ 
grams.  ff  a  programming  problem  is 
assigned  to  a  class  of  200.  the 
students  will  write  200  different  pro¬ 
grams  (assuming  that  they  do  not 
cheat).  There  is  variability  both  in  their 
programs'  designs  and  bugs  Some 
bugs  such  as  missing  variable  Ini¬ 
tializations  are  accidental  omissions 
that  can  be  easily  recognized  and  cor¬ 
rected.  Other  bugs  result  when  the 
programmer  fails  to  reason  through 
the  interactions  between  com¬ 
ponents.  In  isolation,  each  piece  of 
the  program  may  appear  correct  but 
when  combined,  the  program  doesn't 
work.  Still  other  bugs  result  from 
misconceptions  about  programming. 
The  code  may  appear  correct  to  the 
programmer,  but  it  doesn't  do  what 
he  or  she  expects  for  reasons  he  or 
she  does  not  understand.  Bugs  result¬ 
ing  from  misconceptions  are^jhe  most 
serious:  students  stand  to  benefit  the 
most  from  having  such  problems 
pointed  out  to  them. 

If  a  debugging  system  is  to  cope 
with  the  various  types  of  errors  that 
programmers  make  it  must  under¬ 
stand  what  the  programmer  is  trying 
to  da  Debugging  systems  usually 
don't  concern  themselves  with  what 


the  program  is  supposed  to  do.  they 
only  analyse  what  the  program  actual¬ 
ly  does  isee  references  I.  2.  and  3). 
Figuring  out  how  a  program  is  sup¬ 
posed  to  work  is  not  easy:  to  do  it  a 
debugger  requires  information  about 
the  programming  problem  and  knowl¬ 
edge  about  how  to  write  programs 
Nevertheless  identifying  the  program¬ 
mer's  intentions  is  worth  the  effort, 
because  this  knowledge  makes  it 
possible  to  identify  more  bugs,  as  well 
as  to  understand  their  causes 

1b  show  how  knowledge  of  the  pro- 
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1.  Introduction 

In  this  document  we  present  the  inner  workings  of  Micro-PROUST.  Our  intent  is  to  enable 
those  who  so  are  inclined  to  see  at  a  nuts  and  bolts  level  how  a  system  like  PROUST  actually 
works.  We  reprint  here  a  paper  on  PROUST/Micro-PROUST  that  recently  appeared  in  BYTE 
Magazine  that  should  provide  a  good  overview  of  the  operation  of  the  system.  Next,  we  present 
the  design  document  that  was  used  to  code  to  Micro-PROUST;  the  actual  implementor  of  Micro- 
PROUST  found  this  document  thorough  and  comprehensive.  The  third  document  is  a 
preliminary  comparions  of  the  costs/benfits  and  techniques  employed  by  PROUST  and  Micro- 
PROUST.  The  actual  LISP  code  follows  these  papers. 

Micro-PROUST  was  written  for  the  IBM  PC,  in  Golden  LISP.  This  version  of  LISP  is 
available  from  Golden  Hill  LISP,  Inc.,  Cambridge,  Mass.  Micro-PROUST  requires  512K  to  run. 
The  source  code  for  Micro-PROUST  is  available  on  diskette  from  us  for  the  cost  of  the  diskette 
and  handling;  those  interested  should  write  to  the  Cognition  and  Programming  Project,  Yale 
Computer  Science  Department.  The  source  is  also  available  on  the  BYTE  network;  please  refer 
to  the  article  on  PROUST  that  appeared  in  BYTE  for  information  on  how  to  download  the  code; 
that  article  is  reproduced  elsewhere  in  this  document. 

We  are  currently  porting  Micro-PROUST  to  the  VAX  in  order  to  convert  it  to  Franz  LISP. 
Thus,  we  plan  to  distribute  the  source  to  Micro-PROUST  on  magnetic  tape;  again,  if  you  are 
interested  in  receiving  Micro-PROUST  on  this  medium  write  to  the  address  given  above. 

As  noted  expressly  in  the  code  itself,  we,  nor  the  actual  implementors  make  no  promises  for 
Micro-PROUST.  While  we  are  pleased  with  Micro-PROUST  as  a  demonstration  vehicle,  we  do 
not  guarantee  that  it  is  bug  free.  We  would,  of  course,  be  interested  in  receiving  bug  reports. 
Moreover,  their  is  no  additional  documentation  for  the  code  that  is  not  included  here;  that’s  all 
there  is.  Good  luck! 
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ABSTRACT 

PROUST  is  a  system  that  can  identify,  for  a  class  of  moderately  complex  introductory  looping 
assignments,  the  non-syntactic  bugs  in  novices’  programs.  PROUST  is  a  15,000  LISP  program 
and  runs  on  a  VAX.  Micro-PROUST  is  a  program  meant  to  capture  the  essence  of  PROUST. 
Micro-PROUST  is  a  1500  line  LISP  program  and  runs  a  an  IBM  PC  (with  512K).  In  this 
document  we  present  the  inner  workings  of  Micro-PROUST.  Our  intent  is  to  enable  those  who 
so  are  inclined  to  see  at  a  nuts  and  bolts  level  how  a  system  like  PROUST  actually  works. 
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1.  Introduction 

This  document  describes  the  design  of  Micro-PROUST,  a  stripped-down  version  of 
PROUST  |1,  2).  Micro-PR  OUST  is  &  knowledge-based  Eystem  which  identifies  a  certain  class  of 
non-syntactic  bugs  in  novice  programs.  It  uses  a  single,  uniform  mechanism  for  analyzing  buggy 
programs,  unlike  the  full  PROUST  system,  which  employs  various  reasoning  techniques  in  order 
to  understand  students’  programs.  The  following  are  included  in  this  description  of 
Micro- PROUST: 

•  sample  programming  problems  and  solutions  which  Micro-PROUST  should  be  able  to 
handle; 

•  the  design  of  Micro-PROUST;  and 

•  a  description  of  the  knowledge  bases  required  in  order  to  make  Micro-PROUST  run 
on  the  examples  given. 

This  design  has  been  constructed  with  a  Common  Lisp  environment  in  mind.  Modifications 
may  be  required  to  get  this  system  to  run  in  some  other  environment. 

1.1.  Overview  of  the  system 

Micro-PROUST  analyzes  programs  using  an  &nalysis-by-synthesis  approach.  The  system  takes 
as  input  a  description  of  a  programming  problem,  and  a  program.  The  problem  description  is  a 
list  of  goals  which  the  program  must  satisfy.  Micro-PROUST  uses  the  problem  description  to 
try  to  build  an  implementation  model  for  the  program.  It  does  this  by  using  a  database  of 
programming  knowledge  to  suggest  ways  in  which  the  goals  in  the  problem  description  might  be 
implemented.  A  separate  knowledge  base  of  bugs  is  used  to  identify  bugs  given  the 
implementation  model. 

The  following  knowledge  bases  are  required: 

•  a  knowledge  base  of  goals,  indicating  how  these  goals  might  be  implemented  using 
plans; 

•  a  knowledge  base  of  plans;  and 

•  a  rule  base  of  rules  for  identifying  bugs.  ^ 

The  system  itself  has  the  following  main  modules: 


•  a  lexer  and  parser  for  Pascal; 


•  ft  goal  selection  and  implementation  mechanism; 

•  a  plan  matcher; 

•  &  bug  rule  applier;  and 

•  a  bug  description  generator. 


2.  Test  examples  for  Micro-PROUST 


2.1.  Problems  for  Micro-PROUST  to  analyte 
Figures  2-1  and  2-2  show  two  different  programming  problems  which  Micro-PROUST  should 
be  able  to  handle.  The  first,  the  Average  Problem,  is  extremely  simple.  The  second,  the 
Rainfall  Problem,  is  an  elaboration  of  the  Average  Problem. 

Read  in  numbers,  taking  their  sum,  until  the  number  99999  is  seen.  Report  the 
average.  Do  not  include  the  final  99999  in  the  average. 

Figure  2-1:  The  Average  Problem 

Noah  needs  to  keep  track  of  rainfall  in  the  New  Haven  area  in  order  to  determine 
when  to  launch  bis  ark.  Write  a  program  which  he  can  use  to  do  this.  Your  program 
should  read  the  rainfall  for  each  day,  stopping  when  Noah  types  "99999*,  which  is  not 
a  data  value,  but  a  sentinel  indicating  the  end  of  input.  If  the  user  types  in  a  negative 
value  the  program  should  reject  it,  since  negative  rainfall  is  not  possible.  Your 
program  should  print  out  the  number  of  valid  days  typed  in,  the  number  of  rainy 
days,  the  average  rainfall  per  day  over  the  period,  and  the  maximum  amount  of 
rainfall  that  fell  on  any  one  day. 

Figure  2-2:  The  Rainfall  Problem 


2.2.  Programs  for  Micro-PROUST  to  analyse 
2.2.1.  Example  1 

This  example,  shown  in  Figure  2-3,  is  shown  in  Figure  2-3.  The  output  which  Micro-PROUST 
should  generate  is  shown  in  Figure  2-4. 


2.2.2.  Example  2 

Here  is  another  example  averaging  program. 
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1  PROGRAM  Average2(  input,  output  ); 

2  VAR  Sum,  Count.  New:  INTEGER; 

3  Avg:  REAL; 

4  BEGIN 

5  Sum  :=  0; 

6  Count  :=  0; 

7  New  :=  0; 

8  WHILE  New<>99999  00 

9  BEGIN 

10  Read(  New  ); 

11  Sum  :=  Sum+New; 

12  Count  :=  Count+1; 

13  END; 

14  IF  Counts  THEN 

15  Writeln(  *No  data  entered*  ) 

16  ELSE 

17  BEGIN 

18  Avg  :=  Sum/Count; 

19  Writeln(  'The  average  Is  *,  avg  ); 

20  END 

21  END; 

Figure  2-5:  Averaging  program  #2 

1.  You’re  missing  a  sentinel  guard.  When  your  program  reads  the  sentinel,  it  processes 
it  as  if  it  were  data. 

Figure  2-6:  Output  for  averaging  problem  #2 
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2.2.3.  Example  3 

Here  is  a  solution  to  the  Rainfall  Problem. 
PROGRAM  NOAH  (INPUT  .OUTPUT); 

VAR 

RAINFALL.  LARGEST,  SUM.  C0UNT1, 

C0UNT2,  AVERAGE.  RAINYDAYS  :  REAL; 


BEGIN 

(*  INITIALIZE  VARIABLES  *) 

LARGEST  :=0; 

SUM 

C0UNT1  :=0; 

C0UNT2  :=0; 

AVERAGE  :=0; 

RAINYDAYS  :=0; 

(•  READ  THE  RAINFALL  AND  CHECK  FOR  ERROR  VALUES  *) 

VRITELN  (‘ENTER  RAINFALL.  WHEN  YOU  ARE  FINISHED  ENTER  99999'); 

READLN; 

READ  (RAINFALL) ; 

WHILE  RAINFALL  <>  99999  DO 
BEGIN 

WHILE  RAINFALL  <0  DO 
BEGIN 

WRITELN  (RAINFALL  :8. 'IS  NOT  A  POSSIBLE  RAINFALL.  TRY  AGAIN.'); 
VRITELN  CENTER  RAINFALL'); 

READLN; 

READ  (RAINFALL) 

END; 

IF  RAINFALL  >  LARGEST 
THEN 

LARGEST  :=  RAINFALL; 

IF  RAINFALL  >  0 
THEN 

C0UNT2  :=  C0UNT2  ♦  1 ; 

C0UNT1  ;=  COUNT 1  4  1; 

SUM  :=  SUM  4  RAINFALL; 

READLN; 

READ  (RAINFALL) 

END; 

AVERAGE  :=  SUM/COUNT Li  ' 

VRITELN  (C0UNT1  :B.  'VALID  RAINFALLS  WERE  ENETERED.*); 

VRITELN  ('THE  AVERAGE  RAINFALL  WAS'.  AVERAGE  :8.  'INCHES  PER  DAY.'); 
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VRITELN  ('THE  HIGHEST  RAINFALL  WAS'.  LARCEST  :0:2.  'INCHES'); 
VRITELN  ('THERE  WERE',  C0UNT2  :0:2.  'RAINYDAYS  IN  THIS  PERIOD.') 
END. 


Micro-PROUST’s  output  should  look  something  like  this: 

1/  You're  missing  s  sentinel  guard.  If  s  sentinel  value  is  input 
immediately  following  a  negative  value,  your  program  will  process  it  as 
if  it  were  data. 

2.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  50  is  executed.  The  average  is  not  defined  when 
there  is  no  input. 

3.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  46  is  executed.  The  average  is  not  defined  when 
there  is  no  input. 

4.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  51  is  executed.  The  maximum  is  not  defined  when 
there  is  no  input. 


23.  April  1985 
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2.2.4.  Example  4 

Here  is  another  example  Rainfall  Program. 

PROGRAM  RAINFALL  (  INPUT, OUTPUT  ); 

VAR 

RAIN.  DAYS.  TOTALRAIN,  RAINDAYS,  HIGHRAIN.  AVERAIN:  REAL; 

BEGIN 
DAYS  :=  0; 

TOTALRAIN  :=  0; 

RAINDAYS  :=  0; 

HIGHRAIN  :=  0; 

REPEAT 

VRITELN  ('ENTER  RAINFALL'); 

READLN; 

READ  (RAIN); 

WHILE  RAIN  <>  99999  DO 
BEGIN 

DAYS  :=  DAYS  ♦  1 ; 

TOTALRAIN  :=  TOTALRAIN  4  RAIN; 

IF  RAIN  >  0  THEN 
RAINDAYS  ;=  RAINDAYS  ♦  1; 

IF  HIGHRAIN  <  RAIN  THEN 
HIGHRAIN  :=  RAIN. 

END; 

UNTIL  RAIN  =  99999; 

AVERAIN  ;=  TOTALRAIN  /  DAYS; 

WRITELN; 

VRITELN  (  DAYS:0:0. 'VALID  RAINFALLS  WERE  ENTERED'); 

WRITELN; 

WRITELN  ('THE  AVERAGE  RAINFALL  WAS'. AVERAIN:0: 2. 'INCHES  PER  DAY'); 
WRITELN; 

WRITELN  ('THE  HIGHEST  RAINFALL  WAS' ,HIGHRAIN:0:2, ’INCHES’) ; 
WRITELN; 

WRITELN  (’THERE  WERE' .RAINDAYS :0:0, 'IN  THIS  PERIOD’); 

END. 


The  output  from  Micro-PROUST  should  look  something  like  this: 

1.  You  used  •  WHILE  statement  at  line  19  vhere  you  should  have  used  an  IF 

2.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  S5  Is  executed.  The  average  is  not  defined  when 
there  Is  no  Input. 
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3.  You  need  a  test  to  check  that  at  least  one  valid  date  point  has  been 
input  before  line  30  is  executed.  The  average  is  not  defined  when 
there  is  no  input. 

4.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  37  is  executed.  The  max imum  is  not  defined  when 
there  is  no  input. 

5.  Your  program  does  not  perform  an  input  validation. 


23.  April  1685 
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2.2.5.  Example  5 

PROGRAM  TEST1 (INPUT.  OUTPUT); 

VAR 

SUM, N. MAX, AVE: REAL; 

COUNT, RAINY: INTEGER; 

BEGIN 

SUK:=0; 

COUNT  :=©; 

RAINY  :=0; 

MAX:=0; 

WRITELN( 'ENTER  RAINFALL'); 

READLN; 

READ(N) ; 

WHILE  N<>99999  DO 
BEGIN 

IF  N<0  THEN 

VRITELN(N;0:2. '  IS  NOT  A  POSSIBLE  RAINFALL, TRY  AGAIN*); 

ELSE 

BEGIN 

COUNT  :=COLWT*l  ; 

SUM:=SUM+1 ; 

IF  N>0  THEN 
RAINY  :=RAINY-H; 

IF  N>MAX  THEN 
N:=MAX; 

END; 

WRITELN( 'ENTER  RAINFALL'); 

READLN; 

READ(N) 

END; 

VRITELN ; 

IF  C0UNT=0  THEN 

VRITELN (COUNT :0. '  VALID  RAINFALLS  WERE  ENTERED.'); 

ELSE 

BEGIN 

AVE  :s=SUM/COUNT ; 

WRITELNCTHE  AVERAGE  RAINFALL  WAS  \AVE:0:2,’  INCHES  PER  DAY.'); 
VRITELN ('THE  HIGHEST  RAINFALL  WAS  \MAX:0:2.'  INCHES.*); 

VRITELN  ('THERE  WERE  ',RAINY:0,  ’  RAINY  DAYS  IN  THIS  PERIOD.  *) 
END 

END. 

PROUST’s  output: 

You  sre  using  •  counter  update  instead  of  •  running-total  update  st 
line  22.  You  aust  add  the  nev-value  variable  to  SUM,  not  add  1  to  it. 


The  assignment  at  line  26  is  backwards.  This  line  will  assign  to 
N;  you  need  to  assign  to  MAX. 


23.  April  1985 
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2.2.6.  Example  6 

PROGRAM  7EST1 (INPUT ,  OUTPUT); 

VAR 

SUM, N. MAX. AVE: REAL; 

COUNT, RAJ NY: INTEGER; 

BEGIN 

WRITELN (’ENTER  RAINFALL’); 

READLN; 

READ(N); 

WHILE  N099999  00 
BEGIN 

IF  N<0  THEN 

WRITELN(N:0:2. '  IS  NOT  A  POSSIBLE  RAINFALL, TRY  AGAIN’) 

ELSE 

BEGIN 

SUM:=SUM+N; 

COUNT :=C0UNT+1 ; 

IF  N>HAX  THEN 
MAX:=N; 

IF  N>0  THEN 
RAINY :=RAINY+1 ; 

END; 

WRITELN (’ENTER  RAINFALL’); 

READLN; 

READ(N) 

END; 

WRITELN; 

IF  COUNT =0  THEN 

WRITELN (COUNT :0.’  VALID  RAINFALLS  WERE  ENTERED.’); 

ELSE 

BEGIN 

AVE:=SUM/COUNT; 

WRITELN (’THE  AVERAGE  RAINFALL  WAS  \AVE:0:2.’  INCHES  PER  DAY.’);  " 
WRITELN ('THE  HIGHEST  RAINFALL  WAS  ’.MAX:0:2.’  INCHES.’); 

WRITELN  (’THERE  WERE  \RAINY:0,’  RAINY  DAYS  IN  THIS  PERIOD.  ’) 

END 

END. 

PROUST’*  output; 

1.  You  did  not  initialize  •  sun. 

2.  You  did  not  initial  1 ze  a  counter. 

3.  You  did  not  initialise  a  maximum  computation.  r 

4.  You  did  not  initialize  a  counter. 


■  VA 


i  *  •  f  ■  a  ili  mJbdktmt 
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3.  Top-level  organization  of  Micro- PROUST 

The  top-level  processing  is  as  follows. 

1.  Take  as  input  a  problem  description,  and  a  file  name  containing  the  student's 
program. 

2.  Parse  the  file,  generating  a  parse  tree. 

3.  Load  the  goal  agenda  with  the  problem  description.  (The  goal  agenda  is  described  in 
Section  6.) 

4.  Retrieve  plans  for  realizing  each  goal. 

5.  Match  against  the  plans  against  the  program. 

6.  If  a  plan  matches,  add  it  to  the  list  of  plans  that  have  been  matched  so  far. 

7.  Otherwise  apply  bug  rules  in  order  to  explain  the  errors  in  matching  the  plans. 

8.  When  the  goal  agenda  is  empty,  report  the  bugs  to  the  student. 


The  following  is  a  list  of  the  main  routines  in  Micro-PROUST.  More  detailed  descriptions  of 
some  of  these  modules  will  appear  in  subsequent  sections. 

•  (MPROJST  filename  problem )  —  this  is  the  top-level  routine  of  Micro-PROUST. 
filename  is  the  name  of  the  student’s  program,  and  problem  is  the  problem 
description. 

•  (PARSE  filename')  —  parse  filename,  and  return  a  pointer  to  the  root  of  the  parse 
tree. 

•  (INIT-AGENDA  problem)  —  initialize  the  goal  agenda. 

•  (PROCESS-NEXT -GOAL)  -  select  a  goal  from  the  agenda,  retrieve  plans  for  it,  match  the 
plans  against  the  program,  and  identify  bugs. 

•  (REPORT-BUGS)  —  describe  the  bugs  which  have  been  found  to  the  student. 


The  calling  hierarchy  of  these  routines  is  as  follows: 

MPR0U5T 

«  ' 
PARSE  INIT-AGENDA  PROCESS-NEXT-GOAL  REPOkf-BUGS 


These  following  global  variables  are  used  in  this  process: 
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•  *PARSE-TREE*  —  the  parse  tree 

•  ^AGENDA*  —  the  goal  agenda 

•  *ACTIVE-<JOAL*  —  the  current  goal 

•  *ANALYZED-GOALS*  —  the  goals  which  have  been  analyzed  so  far 

•  *BUG-REPORT*  -  the  bugs  which  have  been  found  so  far. 

4.  The  parser 

You  will  have  to  build  a  lexer  and  parser  for  Pascal.  You  may  borrow  the  one  in  PROUST, 
but  it  is  written  in  T,  not  Common  Lisp,  so  you  would  have  to  translate  it.  Assuming  that  you 
write  your  own,  it  should  contain  the  following  routines: 

•  (PARSE  filename )  -  parse  the  program  contained  in  the  file  named  "filename". 
Generate  a  syntax  tree  for  the  program,  and  return  the  parse  tree  node  for  the  root 
of  the  program. 

•  (LEX-IMTIALIZE  filename  )  —  open  the  file  and  initialize  the  input  stream  to  the 
beginning  of  the  file.  Initialize  the  lexer.  Return  T  if  successful. 

•  (LEX-GETTOK)  -  get  a  token.  Return  the  token  type,  and  set  "TOK-VAL*  to  the 
token  value.  Set  ‘TOK-LINE*  to  the  line  number  in  the  program  which  the  token 
appears  on.  Token  types  and  token  values  are  discussed  in  Section  <4.1. 


The  calling  hierarchy  is  as  follows: 

PARSE 

LEX-INITIALIZE  LEX-GETTOK 


1  will  not  discuss  here  the  method  for  constructing  the  Pascal  parser;  there  exist  various  books 
on  compiler  construction  which  discuss  how  this  can  be  done.  The  method  that  we  used  in 
Proust  was  to  modify  the  Unix  yacc  program  to  make  it  generate  Lisp  code.  Note  that  it  is  not 
necessary  to  construct  a  complete  parser  for  Pascal;  in  particular,  there  is  no  need  to  make  the 
parser  handle  procedures  or  complex  datatypes.  Therefore  the  parser  should  be  fairly  simple. 
Whatever  method  you  use  for  implementing  your  parser,  make  sure  that  it  generates  parse  trees 
such  as  those  described  in- Section  4.2.  * 
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1  PROGRAM  NOAH  (DFUT  .OUTPUT) , 

2 

3  VAR 

4 

5  RAINFALL.  LARGEST,  SIM,  CONTI. 

6  COUNTS,  AVERAGE,  RAINYDAYS  :  REAL; 

7 

8 

9  BEGIN 

10  (*  INITIALIZE  VARIABLES  •) 

11  LARGEST  =0; 

12  SW  ;=0; 

13  CONTI  ;=0; 

14  CONT2  M): 

15 

16  AVERAGE  =0; 

17  RAINYDAYS  :=0; 

18  (*  READ  TJ£  RAINFALL  Af©  0€CK  FOR  BtROR  VALUES  *) 

19  WRTTELN  C0.TER  RAINFALL.  YOU  ARE  FINS€D  BfTER  999990; 

READLN, 

READ  (RAINFALL) , 

WHILE  RAIfFALL  O  99999  DO 
BEGIN 

WHILE  RAINFALL  <0  DO 
BEGIN 

WRTTELN  (RAINFALL  :8,’IS  NJT  A  POSSIBLE  RABFALL,  TRY  AGAIN.’); 
WRTTELN  (’ENTER  RAIAFALL’), 

READLN; 

READ  (RAUF ALL) 

END. 

IF  RAINFALL  >  LARGEST 
THEN 

LARGEST  •=  RABFALL; 

IF  RAINFALL  >  0 
7H3J 

C0UNT2  :=  COUNTS  +  1; 

CONTI  -  CDUNT1  +  1. 

9LM  =  SLM  ♦  RAINFALL, 

READLN, 

READ  (RAINFALL) 

eo. 

AVERAGE  :=  OM/CONTl, 

WRTTELN  (C0LNT1  8,  ‘VALID  RAINFALLS  V&E  0ETERS5.  ’); 

WR1TRN  (’THE  AVBVCE  RAINFALL  WAS’,  AVERAGE  :8,  ’INO€S  PER  DAY.’); 
WRTTELN  ('THE  HIGHEST  RA1JFALL  WAS’.  LARGEST  :0:2.  ’INOES’); 

WRTTELN  (’THERE  «€’.  COUNTS  :0:2,  ’RAINYDAYS  IN  THE  PBTTOD.’) 

49  BO 


Figure  2:  An  example  solution  of  the  Rainfall  Problem 
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Noah  needs  to  keep  track  of  rainfall  in  the  New  Haven  area  in  order  to  determine 
when  to  launch  his  ark.  Write  a  Pascal  program  that  will  help  him  do  this.  The 
program  should  prompt  the  user  to  input  numbers  from  the  terminal;  each  input 
stands  for  the  amount  of  rainfall  in  New  Haven  for  a  day.  Note:  since  rainfall  cannot 
be  negative,  the  program  should  reject  negative  input.  Your  program  should  compute 
the  following  statistics  from  this  data: 

1.  the  average  rainfall  per  day; 

2.  the  number  of  rainy  days. 

3  the  number  of  valid  inputs  (excluding  any  invalid  data  that  might  have  been 
read  in); 

4  the  maximum  amount  of  rain  that  fell  on  any  one  day. 

The  program  should  read  data  until  the  user  types  99999;  this  is  a  sentinel  value 
signaling  the  end  of  input.  Do  not  include  the  99999  in  the  calculations.  Assume  that 
if  the  input  value  is  non-negative,  and  not  equal  to  99999,  then  it  is  valid  input  data. 

Figure  1:  The  Rainfall  Problem 

in  terms  of  its  intended  function,  e.g.,  outputting  the  maximum,  or  checking  for  invalid  input. 
PROUST  also  generates  an  example  of  input  data  which  will  cause  the  program  to  perform 
incorrectly,  to  ensure  that  the  programmer  sees  that  the  intended  function  has  not  been  properly 
realized.  In  this  case  the  suggested  input  sequence  is  5,  -5,  99999. 

4.  Application  of  Intention-Based  Diagnosis  in  PROUST 

PROUST’s  methods  for  analyzing  bugs  based  on  intentions  has  been  discussed  in  detail 
elsewhere  [6,  3,  5,  4].  We  will  focus  here  on  some  of  the  key  features  of  PROUST’s  approach. 
Then,  in  the  next  section,  we  will  compare  the  way  that  these  features  are  realized  in  PROUST 
with  the  way  that  they  are  implemented  in  Micro-PROUST. 

PROUST  bases  its  analysis  of  each  program  on  a  description  of  the  problem  that  the  student  is 
working  on.  PROUST  is  intended  to  be  used  in  an  introductory  programming  course,  where  the 
students  are  expected  to  complete  a  series  of  programming  assignments.  PROUST  is  supplied 
wdth  a  description  of  each  assignment  that  the  students  will  be  working  on.  Each  problem 
description  indicates  the  type  of  data  that  the  program  must  process,  and  the  primary  goals  that 
must  be  achieved  by  the  program.  They  indicate  what  the  programs  must  do,  but  not  how  they 
should  do  it.  The  problem  descriptions  frequently  leave  out  some  details,  which  the  programmer 
is  assumed  to  know  to  fill  in.  The  problem  descriptions  thus  supply  essential  information  about 
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errors  in  the  programmer’s  intentions,  or  as  errors  in  the  realization  of  those  intentions. 

It  is  intuitively  obvious  to  most  programmers  that  a  good  understanding  of  the  intended 
function  of  a  program  is  necessary  in  order  to  debug  a  program  accurately.  Some  bugs  may  be 
identified  without  reading  the  code,  but  frequently  a  person  must  read  a  program  carefully  in 
order  to  diagnose  bugs  and  suggest  an  appropriate  correction  for  them.  Nevertheless,  automatic 
debugging  systems  tend  to  analyze  program  behavior,  without  reference  to  underlying  intentions 
[8,  1,  2,  7,  11],  Such  methods  can  fail  when  the  program  runs,  but  generates  incorrect  results. 
PROUST  is  unique  in  its  reliance  on  an  explicit  description  of  the  intentions  underlying 
programs. 

3.  An  illustration  of  intention-based  diagnosis 

In  order  to  illustrate  how  knowledge  of  intentions  is  needed  when  debugging  programs,  we  will 
discuss  an  example  buggy  program  and  show  how  it  is  debugged.  The  example  is  a  solution  to 
the  problem  shown  in  Figure  1,  which  we  will  be  refer  to  as  the  Rainfall  Problem.  This  problem 
requires  that  a  series  of  inputs  be  read,  which  signify  the  amount  of  rainfall  per  day.  The  end  of 
input  is  signaled  when  the  user  types  99999;  we  will  refer  to  this  value  as  the  sentinel  value. 
The  program  must  perform  various  computations  on  these  data,  such  ac  finding  the  average  and 
the  maximum.  It  must  also  ensure  that  the  data  that  is  entered  is  valid,  i.e.,  negative  daily 
rainfall  must  be  rejected. 

Figure  2  shows  an  actual  student  solution  to  the  Rainfall  Problem.  This  program  has  several 
bugs.  If  the  user  types  99999  without  first  entering  rainfall  data,  the  program  divides  by  zero  at 
line  43,  and  then  prints  out  meaningless  results  at  lines  46  and  47.  In  addition,  the  test  for 
invalid  input,  starting  at  line  24,  has  a  bug.  If  the  user  types  99999  immediately  after  an  invalid 
value,  the  99999  will  not  be  recognized  as  the  signal  of  input  termination.  Instead,  the  99999  will 
be  processed  as  data  We  claim  that  knowledge  of  the  intended  function  of  this  program  is 
needed  in  order  to  debug  the  program.  In  particular,  we  need  to  know  what  range  of  inputs  the 
program  is  supposed  to  handle,  and  what  results  it  should  generate  for  these  inputs.  For 
example,  if  we  did  not  know  that  99999  should  not  be  processed  as  data,  we  would  not  be  able  to 
determine  that  the  program  behaves  incorrectly  when  99999  is  input  after  a  negative  input 

PROUST’s  analysis  of  the  program  iu  Figure  2  is  shown  in  Figure  3.  This  analysis  makes 
frequent  reference  to  the  intentions  underlying  the  program.  It  describes  each  buggy  line  of  code 
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1.  Introduction 

As  a  first  step  in  developing  tools  that  can  aid  novice  programmers  when  they  are  learning  to 
program,  we  have  designed,  built  and  classroom  tested  a  program  called  PROUST  that  can 
identify  the  non-syntactic  bugs  in  novices’  programs.  Currently,  PROUST  operates  on  a  class  of 
moderately  complex  looping  programs  in  Pascal  that  are  typical  assignments  in  an  introductory 
programming  course.  PROUST  provides  students  with  a  list  of  the  non-syntactic  bugs  in  their 
programs  and  suggestions  about  the  misconceptions  that  they  may  be  laboring  under  that  are 
responsible  for  the  bugs.  PROUST  can  correctly  identify  approximately  75%  of  the  bugs  in  the 
students  programs. 

PROUST  is  a  15,000-line  LISP  program  which  runs  on  a  VAX  750  with  several  megabytes  of 
memory.  As  such,  PROUST  cannot  run  on  a  personal  computer.  In  a  project  sponsored  by 
Courseware,  Inc.  we  undertook  to  design  a  micro  version  of  PROUST  that  would  be  able  to  run 
on  an  IBM  PC.  Our  purposes  in  undertaking  this  project  were  twofold.  First,  PROUST  is  a 
very  complex  program;  we  believed  that  it  would  be  instructive  to  strip  PROUST  down  to  its 
barest  essentials,  so  others  would  be  able  to  see  more  clearly  how  PROUST  works.  Second,  we 
wished  to  demonstrate  the  feasibility  of  developing  an  Al-based  system  for  a  personal  computer. 
To  these  ends,  our  project  has  been  a  success:  in  this  paper  we  briefly  describe  the  architecture 
of  Micro-PROUST.  However,  Micrc^PROUST  as  it  stands  is  not  powerful  enough  to  use  as  an 
educational  tool.  We  will  discuss  in  Section  7  what  will  be  required  to  expand  MicrcvPROUST 
sufficiently  to  make  it  a  useful  product,  while  at  the  same  time  staying  within  the  space 
limitations  of  personal  computers. 

The  organization  of  this  paper  is  as  follows.  First,  we  briefly  describe  the  architecture  of 
PROUST,  and  talk  about  the  features  of  PROUST  that  have  been  incorporated  into  Micrc^ 
PROUST.  A  comparison  of  the  two  systems  is  made.  We  conclude  by  discussing  the  prospects 
of  building  a  product  version  of  MicroPROUST  that  will  perform  at  an  acceptable  level  in  a  real 
educational  setting. 

2.  Intention-Based  Diagnosis 

The  key  idea  underlying  PROUST’s  approach  is  intention-based  diagnosis.  That  is,  PROUST 
identifies  the  non-syntactic  bugs  in  a  program  by  determining  what  the  program  is  intended  to 
do,  and  then  relating  these  intentions  to  the  actual  code.  Bugs  then  become  apparent  either  as 
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(DPS  LOOP-INPUT-VALIDATION 
INSTANCES 

(BAD-INPUT-SKIP-GUARD 
BAD-INPUT -LOOP-C 


INIT-AGENDA 


PROCESS-NEXT-GOAL 


GET-NEXT-GOAL  INSTANTIATE  PROCESS-PLANS 


7.  Tbe  goal  database 

In  order  to  process  escb  goal,  PROUST  must  look  tbe  goal  up  in  tbe  goal-plan  database,  in 
order  to  determine  bow  the  student  might  have  implemented  tbe  goal.  Information  about  goals 
is  stored  on  tbe  property  list  of  the  goal.  Tbe  following  properties  are  used: 

•  INSTANCES  —  a  list  of  plans  which  can  be  used  to  implement  tbe  goal 

•  NAME-PHRASE  —  a  string  indicating  in  English  the  function  of  tbe  goal. 


7.1.  The  DPS  macro 

Tbe  following  macro  is  used  to  construct  tbe  goal  knowledge  base,  as  well  as  other  knowledge 
bases. 

•  DPS(  var  slotl  Jillerl  slots  fillers  ...)  -  adds  properties  slotl,  slots,  etc.  to  the 
property  list  of  var.  DPS  does  not  evaluate  its  arguments. 


Example: 

(DPS  FIDO 

SPECIES  CANIS-FAKILIARIS 
AGE  8 

SEX  MALE) 


(PUT  ’FIDO  ’SPECIES  ’CANIS-FAM1UARIS) 
(PUT  ’FIDO  ’AGE  8) 

(PUT  ’FIDO  ’SEX  ’MALE) 


7.2.  Example  goal  database 

Tbe  following  database  is  required  in  order  to  handle  tbe  examples  described  in  Section  2. 

(DPS  SENTINEL-CONTROLLED- LOOP 
INSTANCES 

(SENTINEL-READ-PROCESS-WHILE 

SENTINEL-PROCESS-READ-WHILE 

SENTINEL-READ-PROCESS-REPEAT)  ' 

NAME-PHRASE 
•input  processing*) 
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(MAXIMUM  (NEW  .  (*VAR*  NEW  SENTINEL-GONTROLLED-LOOP))) 

(OUTPUT  (VAL  .  (*VAR*  MAX  MAXIMUM))) 

(GUARD-EXCEPTION  (CODE  .  (*VAR*  OUTPUT:  OUTPUT)) 

(PRED  .  (=  (»VAR*  COUNT  COUNT)  0))) 

(CUARD-EXCEPTION  (CODE  .  (*VAR*  UPDATE:  AVERAGE)) 

(PRED  .  (=  (*VAR  COUNT  COUNT)  0))))) 

Note  tbat  some  variables  are  bound  to  an  expression  which  contains  a  *VAR*  form  in  it.  These 
are  used  to  refer  to  variables  defined  by  other  goals.  For  example,  (*VAR*  NEW 
SENTINEL-CONTROLLED-LOOP)  refers  to  the  variable  NEW  in  the  SENTINEL-CONTROLLED-LDOP  goal. 

6.  Processing  the  goal  agenda 

During  processing  of  the  program  the  goal  agenda  is  stored  in  the  variable  "AGENDA*.  The 
goal  currently  being  processed  is  in  the  variable  "ACTIVE-GOAL*.  The  list  of  goals  tbat  have 
already  been  analyzed  is  called  "ANALYZED-GOALS*.  The  processing  of  goals  in 
Micro-PROUST  is  extremely  simple;  the  program  simply  starts  with  the  first  goal  in 
"AGENDA",  processes  each  goal  in  order,  one  at  a  time.  This  continues  until  "AGENDA*  is 
empty. 

After  a  goal  has  been  matched,  and  a  plan  has  been  chosen,  the  goal  and  the  plan  are  stored  in 

♦ANALYZED-GOALS*.  This  is  discussed  further  in  Section  10.3. 

# 

The  following  routines  are  used  to  manipulate  the  goal  agenda: 

•  (INIT-AGENDA  problem  description  )  -  sets  "AGENDA*  to  be  the  list  of  goals 
contained  in  the  problem  description 

•  (PROCESS-NEXT-GOAL)  --  get  the  next  goal  and  process  it.  This  calls  CET-NEXT-COAL  to 
get  the  next  goal  to  process,  then  passes  this  to  INSTANTIATE.  PR0CESS-PLAN5  is  called 
in  order  to  match  the  plans  to  the  code. 

•  (GET-NEXT-GOAL)  —  removes  the  goal  at  the  head  of  *ACENDA*,  and  6tores  it  in 
♦ACTIVE-GOAL*.  Returns  *ACTIVE-G0AL*. 

•  (INSTANTIATE  goal )  -  instantiates  a  goal.  Returns  a  list  of  plan  instantiations.  See 
Section  9. 

•  (PROCESS-PLANS  plans  —  match  the  plans  against  the  dbde.  See  Section  10. 

The  calling  hierarchy  of  these  routines  is: 
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5.  Problem  descriptions 

The  problem  descriptions  for  tbe  two  problems  will  appear  as  follows.  These  problem 
descriptions  are  a  list  of  goals  w'hich  will  have  to  be  satisfied  in  the  student's  program.  For  the 
sake  of  simplicity  we  are  assuming  that  every  goal  that  will  be  realized  in  the  program  will  have 
to  be  included  in  the  problem  description. 


Each  goal  is  a  list  whose  CAR  is  the  type  of  goal  which  is  required,  and  whose  CDR  is  a  list  of 

variable  bindings.  Each  goal  has  a  specific  set  of  free  variables  associated  with  it,  not  ail  of 

which  may  be  listed  in  tbe  bindings  list.  For  example,  SENTINEL-CONTROLLED-LOOP  has  two  free 

variables:  New,  which  is  the  new-value  variable,  and  STOP  which  is  the  stop  value.  Only  STOP  is 

mentioned  in  the  SENTINEL-CONTROLLED-LOOP  goals  that  appear  below.  If  a  variable  does  not 

appear  in  tbe  bindings  list,  it  remains  free,  and  must  be  bound  during  the  process  of  matching 

the  goal  against  the  program.  In  other  words,  Micro-PROUST  determines  the  binding  or  NEW  in 

SENTINEL-CONTROLLED-LOOP  when  examines  the  student's  program  and  discovers  which  Pascal 

variable  in  the  program  corresponds  to  NEW. 

(DEFINE  ♦AVG-SPEC*  '( 

(SENTINEL-CONTROLLED-LOOP  (STOP  .  99999)) 

(COLWT  (NEW  .  (»VAR*  NEW  SENTINEL-CONTROLLEI>-LOOP))) 

(AVERAGE  (NEW  .  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP) ) ) 

(SUM  (NEW  .  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP)) 

(TOTAL  .  (*VAR*  SUM  AVERAGE))) 

(OUTPUT  (VAL  .  (*VAR*  AVG  AVERAGE))) 

(GUARD-EXCEPTION  (CODE  .  (♦VAR*  OUTPUT:  OUTPUT)) 

(PRED  .  (=  (*VAR*  COUNT  COUNT)  0))) 

(GUARD-EXCEPTION  (CODE  .  (*VAR*  UPDATE:  AVERAGE)) 

(PRED  .  (=  (*VAR*  COUNT  COUNT)  0))))) 

(DEFINE  * RAINFALL-SPEC*  '( 

(SENTINEL-CONTROLLED-LOOP  ((»VAR*  NEW  SENTINEL-CONTROLLED-LOOP)  99999)) 
(LOOP-INPUT-VALIDATION  ((*VAR*  NEW  SENTINEL-CONTROLLED-LOOP) 

(<  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP)  0))) 

(AVERAGE  (NEW  7  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP))) 

(COUNT  (NEW  .  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP))) 

(OUTPUT  (VAL  .  (*VAR*  AVG  AVERAGE))) 

(GUARD-EXCEPTION  (CODE  .  (*VAR*  OUTPUT:  OUTPUT)) 

(PRED  .  (=  (*VAR*  COUNT  COUNT)  0))) 

(OUTPUT  (VAL  .  (*VAR*  COUNT  COUNT))) 

(SUM  (NEW  .  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP))  , 

(TOTAL  .  (*VAR*  SUM  AVERAGE))) 

(GUARDED-COUNT  (NEW  .  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP)) 

(PRED  .  (>  (*VAR*  NEW  SENTINEL-CONTROLLED-LOOP)  0))) 

(OUTPUT  (VAL  .  (*VAR*  GUARDED-COUNT  COUNT))) 
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BEGIN 

CASE 

CASE-PART 

CONST-LIST 

WRITE 

VRITELN 

READ 

READLN 

STATEMENT-LIST 

WHILE 

REPEAT 

IF 


a  BEGIN-END  block 

s  CASE  statement 

a  branch  of  a  CASE  statement 

a  I ist  of  constants  referred  to  by  a  CASE-PART 

a  call  to  WRITE 

a  call  to  WRITELN 

a  call  to  READ 

a  call  to  READLN 

an  assignment  statement 

a  list  of  statements;  used  in  REPEAT  and  CASE  statements 
a  WHILE  statement, 
a  REPEAT  statement 
an  IF  statement 


<  relational  expressions 

> 

<= 

>= 

<> 


AND 

logical  expressions 

OR 

NOT 

4 

arithmetic  expressions 

/ 

DIV 

MOD 

strings 

numbers 

identifiers 


Parse  tree  nodes  are  structures  containing  tbe  following  fields: 

•  NAME  -*  the  name  of  tbe  parsetree  node 

•  PARENT  -  the  parent  of  the  node  in  the  parse  tree 

•  CHILDREN  ~  children  or  the  node 

•  LINE  —  the  line  number  where  tbe  code  appears  in  the  student’s  program 


•  MARK  —  T  or  NILrindicales  whether  or  not  the  statdfrienl  has  been  matched  yet. 
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4.2.  Parse  tree  nodes 

Generally  speaking,  there  is  a  node  in  the  syntax  tree  for  each  syntactic  statement,  expression 
and  subexpression  in  the  program.  Each  parse  tree  node  is  labeled  according  to  the  principal 
keyword,  operator,  or  value  in  the  corresponding  statement  or  expression.  The  following 
example  shows  a  fragment  of  Pascal  text  and  the  parse  tree  that  U  generated  for  it. 

WHILE  N<0  DO 
BEGIN 

VRITELN(  N,  'IS  INVALID.  PLEASE  REENTER*  ); 

READC  N  ) ; 

END; 


WHILE 


< 


BEGIN 


N  0 

WRITELN  READ 

N  "IS  INVALID.  PLEASE  REENTER"  N 


Note  that  1  have  chosen  to  use  as  names  of  the  parse  tree  nodes  the  token  values  such  as  N  and 
0,  rather  than  the  token  types,  TOK-IDENTIPIER  and  TOK-NUHBER.  I  also  name  nodes  for  operators 
using  the  actual  operator:  the  top-most  node  denoting  the  expression  N<0,  for  example,  is  <,  not 
TOK-LESS-THAN.  Check  the  Common  Liep  manual:  you  may  have  to  change  this , 

In  the  case  of  statements,  the  name  of  the  parse  tTee  node  is  the  principal  keyword  in  the 
statement.  This  means  that  a  parse  tree  node  for  a  WHILE  statement  is  named  WHILE,  and  the 
parse  tree  node  for  an  assignment  statement  is  named  :=.  There  is  no  parse  tree  node 
corresponding  to  the  keywords  THEN,  DO,  or  END,  so  these  do  not  appear  in  the  tree. 


Here  is  a  list  of  the  kinds  of  parse  tree  nodes  which  are  used  in  Micro-PROUST: 


PROGRAM 

the  root  node  for  the  parse  tree 

PROG-HEADER 

the  I/O  header  of  the  program 

DECLS 

the  declaration  part  of  the  prograe 

CONST -DECLS 

constant  declarations 

var-decls 

variable  declarations 

CONST 

a  constant  declaration 

VAR 

a  variable  declaration 

ID-LIST 

a  1 1st  of  Identifiers 

Lexers  are  also  described  in  detail  in  compiler  construction  texts.  I  leave  the  details  of  the 
lexer  design  to  the  implementor.  However,  ]  should  point  out  that  there  may  be  ways  to  take 
advantage  of  the  Lisp  READ  function  when  constructing  the  lexer  for  Micro-PROUST.  After 
all,  READ  processes  text  and  identifies  numbers  and  atoms,  which  is  a  lexical  analysis  process. 
In  principal  you  could  lex  your  Pascal  programs  by  repeatedly  calling  READ  on  the  Pascal 
program,  and  looking  at  what  READ  returns  to  see  if  it  is  a  number,  an  atom,  or  an  S- 
expression.  Note,  however,  that  to  do  this  will  require  definition  of  read  macros  for  special 
characters  such  as  commas,  semicolons,  and  operators.  Otherwise  if  expressions  such  as  A+B  will 
be  lexed  as  a  single  atom  rather  than  as  A,  *,  and  B. 

Lexical  tokens  are  denoted  using  two  values:  the  token  type  and  the  token  value.  The  token 
type  is  a  code  indicating  the  type  of  token  whieh  has  been  encountered.  These  codes  are  Lisp 
atoms.  Thus  we  might  have  the  following  relationship  between  tokens  and  token  types: 


Token 

Token  Type 

BEGIN 

TOK-BEGIN 

UNTIL 

TOK-UNTIL 

< 

TOK-IESS-THAN 

<> 

T0K-N0T-E5 

• 

TOK-SEMICDLON 

0 

TDK -COMMA 

* 

TOK-HULTIPLY 

- 

TOK -MINUS 

a-pasca l-variable 

TOK-IDENTIFIER 

4.75 

TOK-NUMBER 

’hello  world* 

TOK-STRING 

<end  of  f i le> 

TOK-EOF 

Note  that  in  the  case  of  identifiers,  numbers  and  strings,  the  token  type  is  simply 
TOK-IDENTIFIER,  TOK-NUMBER,  and  TOK-STRING,  respectively.  In  these  cases  the  token  value  is  the 
actual  token,  ».e.,  the  name  of  the  identifier,  the  actual  number  or  string.  In  other  cases  the 
token  value  is  undefined,  since  the  token  type  is  sufficient  to  describe  what  kind  of  token  it  is. 
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Bug  Report 

1.  You’re  missing  a  sentinel  guard.  If  a  sentinel  value  is  input 
immediately  following  a  negative  value,  your  program  will  process  it  as 
if  it  were  data. 

Try  the  following  data  in  your  program  to  see  this: 

5  -5  99999 

Other  bugs: 

2.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  50  is  executed.  The  average  is  not  defined  when 
there  is  no  input. 

3.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  46  is  executed.  The  average  is  not  defined  when 
there  is  no  input. 

4.  You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
input  before  line  51  is  executed.  The  maximum  is  not  defined  when 
there  is  no  input. 

Figure  3:  PROUST’s  output  for  the  example  in  Figure  2 
the  problems,  without  predisposing  PROUST  toward  specific  types  of  solutions. 


When  a  student  submits  a  program  for  analysis  by  PROUST,  PROUST  retrieves  the 
appropriate  problem  description  from  the  problem  description  library.  These  problem 
descriptions  give  PROUST  a  start  at  understanding  the  intended  function  of  the  program. 
PROUST  must  still  go  through  a  considerable  amount  of  effort  in  order  to  understand  how  each 
student  program  is  supposed  to  work.  However,  given  a  description  of  the  problem,  and 
knowledge  base  of  facts  about  programming,  PROUST  is  able  in  most  cases  to  identify  the 
student’s  intentions,  and  use  the  intentions  to  find  the  bugs. 


Program  analysis  is  performed  in  PROUST  using  an  analysis-by-syntbesis  process.  PROUST 
synthesizes  different  ways  of  solving  and  implementing  the  assigned  programming  problem. 
PROUST  must  have  enough  programming  knowledge  that  it  could  write  the  program  itself. 
After  PROUST  synthesizes  a  possible  problem  solution,  it  compares  the  hypothesized  solution  to 
the  student’s  code.  If  there  is  a  match,  then  it  is  likely  that  the  synthesized  solution  fits  the 
student’s  intentions  If  there  is  a  mismatch,  then  either  the  student’s  intentions  do  not  match 
the  synth  sized  solution,  or  else  there  is  a  bug  in  the  realization  of  those  intentions.  PROUST 


then  uses  its  knowledge  of  bugs  to  determine  if  the  mismatches  result  from  bugs.  If  so,  these 
bugs  are  reported  to  the  student. 

Synthesis  of  possible  problem  solutions  involves  two  steps.  First,  PROUST  synthesizes 
alternative  goal  decompositions  for  the  program.  PROUST’s  problem  descriptions  consist  in 
part  of  high-level  descriptions  of  the  goals  which  must  be  satisfied  in  solving  the  problem.  Goal 
decompositions  are  the  relationships  between  the  goals  in  the  problem  statement  and  the  goals 
which  are  actually  implemented  in  the  student’s  program.  The  more  complex  the  programming 
problem  is,  the  more  reasoning  about  goals  the  programmer  has  to  do  in  order  to  put  them  in  a 
form  that  can  be  implemented  in  code.  The  goal  decomposition  records  the  additions, 
modifications,  and  deletions  to  the  original  set  of  goals  which  are  listed  in  the  problem 
description 

The  second  step  in  synthesizing  possible  solutions  is  to  select  programming  plans  to  implement 
the  goals  which  result  after  goal  decomposition.  Programming  plans  are  stereotypic  methods  for 
accomplishing  programming  tasks.  Expert  programmers  make  extensive  use  of  programming 
plans  in  w'riting  and  understanding  programs  [10].  In  PROUST  the  possible  plans  that  the 
student  might  use  to  implement  a  goal  are  all  matched  against  the  program,  to  see  which  fits  the 
code  best. 

When  a  plan  fails  to  match  the  code  exactly,  PROUST  makes  a  note  of  the  differences  between 
the  plans  and  the  code  It  then  uses  a  database  of  plan-difference  rules  to  explain  the  plan 
differences.  These  plan-difference  rules  suggest  bugs  which  could  cause  the  match  failures.  The 
bugs  that  the  plan  difference  rules  identify  are  then  reported  to  the  student. 

To  summarize,  intention-based  diagnosis  in  PROUST  consists  of  the  following  steps: 

•  retrieving  the  appropriate  problem  description, 

•  hypothesizing  goal  decompositions  for  the  program, 

•  hypothesizing  plans  to  implement  the  goal  decompositions, 

•  matching  the  plans  against  the  program,  and 

•  using  plan-difference  rules  to  explain  the  plan  mismatches. 
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5.  PROUST  and  Micro-PROUST 

Micro-PROUST  goes  through  nearly  the  same  process  that  PROUST  does  in  analyzing  buggy 
programs.  Some  of  PROUST’s  analysis  steps  have  been  eliminated,  but  the  resulting  mechanism 
still  retains  most  of  the  essential  features  of  PROUST.  The  features  of  PROUST  which  were 
eliminated  are  those  which  require  substantial  amounts  of  code  to  implement,  and  which  are  not 
necessary  for  analyzing  most  novice  programs.  In  order  to  highlight  the  similarities  and 
differences  between  PROUST  and  Micro-PROUST,  we  will  describe  step  by  step  the  knowledge 
and  processing  required  by  the  two  systems  to  analyze  solutions  to  the  Rainfall  Problem. 

5.1.  Goal  decompositions 

The  main  difference  between  PROUST  and  Micro-PROUST  is  that  whereas  PROUST  bases  its 
analysis  on  problem  descriptions,  and  generates  goal  decompositions  for  each  program, 
Micro-PROUST  bases  its  analysis  on  hand-coded  goal  decompositions  written  by  us.  These  goal 
decompositions  are  organized  into  a  library,  just  as  PROUST’s  problem  descriptions  are 
organized  into  a  library.  When  Micro-PROUST  analyzes  a  program,  it  retrieves  the  appropriate 
goal-decomposition  description,  and  uses  it  to  understand  the  program. 

Micro-PROUST  assumes  that  every  solutioo  to  a  given  programming  problem  will  have  the 
same  goal  decomposition.  This  assumption  is  untenable  for  harder  programming  problems,  but 
it  may  be  tolerable  if  the  programs  are  small. 

In  order  to  understand  the  effect  of  assuming  a  unique  goal  decomposition  per  problem,  let  us 
compare  PROUST’s  problem  description  for  the  Rainfall  Problem  with  Micro-PROUST’s  goal- 
decomposition  description  for  the  same  problem.  Figure  4  shows,  in  a  stylized  form,  PROUST’s 
description  of  the  Rainfall  Problem.  This  problem  description  consists  of  two  parts;  a  set  of 
objects  which  the  program  manipulates,  and  a  set  of  goals  that  must  be  satisfied.  Objects  are 
the  quantities  of  data  that  the  program  should  manipulate.  Two  objects  are  defined  in  this 
example:  ?DailyRain,  the  series  of  rainfall  amounts,  and  ?Sentinel,  the  sentinel  value.  Object 
names  are  indicated  by  a  preceding  question  mark.  The  goals  are  requirements  that  the  program 
must  satisfy.  For  example,  Average  is  the  goal  of  computing  the  average  of  some  set  of  values; 
Output  is  the  goal  of  outputting  a  value  to  the  terminal.  Goal  names  appear  in  italics.  An 
English  paraphrase  of  each  statement  in  the  description  of  the  Rainfall  Problem,  one  line  at  a 
time,  is  shown  in  Figure  5. 


Def i ne-Program  Rainfall; 

Def ine-Object  ?Da i I yRa i n  ObjectClass  Sea larHeasurement; 

Def ine-Object  ?Sentinel  Value  99399; 

Define-Goal  Sentinel-Controlled-Inputi  ?Dsi  lyRain,  ?Sentinel  ); 

Define-Goal  Input-Validationi  ?Dai lyRain.  ?Dai  lyRain  <  0  ); 

Define-Goal  Output (  Average (  ?Dai lyRain  )  ); 

Define-Goal  Outputs  Count(  ?DailyRain  )  ); 

Define-Goal  Outputs  Guarded-Count{  ?Dai lyRain,  ?Dai lyRain  >  0  )  ); 

Define-Goal  Outputs  Maximum (  ?DailyRain  )  ); 

Figure  4:  The  problem  description  for  the  Rainfall  Problem 

•  This  problem  is  called  "Rainfall". 

•  Define  an  object  called  Dai  lyRain;  it  is  a  scalar  measurement,  i.e.,  a  non-negative  real 
number. 

•  Define  an  object  called  Sentinel,  whose  value  is  99999. 

•  Generate  successive  values  of  Dai  lyRain  by  reading  them  from  the  terminal,  stopping 
when  Sentinel  is  read. 

•  Test  Dai  lyRain  for  validity,  by  ensuring  that  Dai  lyRain  <  0  is  never  true. 

•  Output  the  average  of  Dai  lyRain. 

•  Output  a  count  of  the  number  of  values  that  Dai  lyRain  takes. 

•  Output  a  count  of  the  number  of  values  in  Dai  lyRain  for  which  Dai  lyRain  >  0  is  true. 

•  Output  the  maximum  of  Dai  lyRain. 

Figure  5:  A  line-by-line  paraphrase  of  Figure  4 

Figure  6  shows  Micro-PROUST's  goal-decomposition  description  for  the  Rainfall  Problem. 
There  are  a  number  of  differences  between  this  description  and  PROUST’s  problem  descriptions. 
For  example,  there  are  no  object  definitions;  object  processing  was  dispensed  with  in 
Micro-PROUST.  As  a  consequence,  Micro-PROUST  must  assume  that  all  students  will  attribute 
the  same  properties  to  the  data  being  processed.  For  example,  PROUST’s  description  of  the 
Rainfall  Problem  indicates  that  the  object  ?Dai  lyRain  is  a  Sea  larMeasurement,  i.e.,  it  is  a  non¬ 
negative  real  number.  PROUST’s  know  ledge  base  includes  a  description  of  Sea  larHeasurement, 
specifying  that  objects  of  this  type  must  be  nonnegative  and  real.  In  Micro-PROUST  there  is  no 
knowledge  base  of  types  of  objects  All  relevant  facts  about  the  objects  being  processed  are 


incorporated  into  the  goals  which  are  listed  in  the  goal  decomposition,  or  else  are  omitted.  Thus 
the  requirement  that  ?DailyRain  must  be  non-negative  is  enforced  by  the  InputValidation  goal 
which  checks  each  input  of  ?DailyRain  for  validity.  The  fact  that  ’DailyRain  should  be  a  real 
number  is  omitted;  if  a  student  declared  the  input  variable  to  be  an  integer,  Micro-PROUST 
would  fail  to  detect  the  error. 


The  most  significant  difference  between  PROUST’s  description  of  the  Rainfall  Problem  and 
Micro-PROUST’s  description  is  that  several  goals  have  been  added  to  Micro-PROUST ’s 
description  which  are  absent  from  PROUST’s  description.  A  Sum  goal  has  been  added  to 
compute  the  sum  of  the  inputs,  and  three  Guard-Exception  goals  have  been  added  to  check  for 
boundary  conditions,  such  as  division  by  zero.  These  goals  are  added  in  order  to  fill  out  the  goal 
decomposition.  PROUST  would  add  these  goals  automatically  as  needed,  relying  upon  its 
knowledge  about  goals.  In  Micro-PROUST’s  descriptions  every  goal  must  be  made  explicit. 
Furthermore,  Micro-PROUST  assumes  that  every  goal  listed  must  be  explicitly  realized  in  the 
program  using  some  plan.  It  is  possible  to  solve  the  Rainfall  Problem  without  summing  the 
inputs,  and  without  checking  for  division  by  zero;  Micro-PROUST  cannot  understand  such 
solutions  because  they  do  not  fit  the  given  goal  decomposition. 

Sentinel-Contr olied-Inpvti  ?New,  99999  ); 

Input -Validation^  (?Nev  in  goal  Sentinel-Contr  oiled-input) . 

(?Nev  in  goal  Sentinel-Controlled-Input)  <  0  ) ; 

Average  (  (?Nev  in  goal  Sentinel-Contr  olled-Input)  ); 

Count  (  (?New  in  goal  Sentinel-Controlled-Input)  ); 

Output  (  (?Avg  in  goal  Average)  ); 

Guard-Exception  (.  (?0utput:  in  goal  Output) . 

(’Output:  in  goal  Output)  =  0  ); 

Output  (  (?Count  in  goal  Count  ); 

Sum(  (?New  in  goal  Sentinel -Conir olled-Input) , 

(’Sum  in  goal  Average)  )  ; 

Guarded-Count  (  (?New  in  goal  Sentinel-Controlled-Input) , 

(?N ev  in  goal  Sentinel-Controlled-Input)  >  0  ) ; 

Out  put  (  (?Count  in  goal  Guarded-Count)  ); 

Maximum (  (?Nev  in  goal  Sentinel-Controlled-Input)  ); 

Outputs  (?Max  in  goal  Maximum)  ); 

Guard-Exceptiont,  (’Output:  in  goal  Output) . 

(?Count  in  goal  Count)  =  0  ); 

Guard-Exception{  (?Update:  in  goal  Average) . 

(?Count  in  goal  Count)  =  0  ); 

Figure  8:  Micro-PROUST’s  goal  decomposition  for  the  Rainfall  Problem 


5.2.  The  goal  database 

PROUST  and  Micro-PROUST  both  have  knowledge  bases  of  programming  goals.  Each  goal  in 
Micro-PROUST’s  knowledge  base  is  also  in  PROUST’6  knowledge  base.  However, 
Micro-PROUST’s  knowledge  base  contains  less  information  about  each  goal.  All  knowledge 
needed  in  PROUST  in  order  to  construct  goal  decompositions  has  been  removed,  since 
Micro-PROUST  cannot  construct  goal  decompositions  automatically.  What  is  left  are  the  names 
of  plans  which  implement  the  goal,  and  an  English  phrase  describing  the  goal.  Figures  7  and  8 
show  the  same  goal,  Input-Validation,  as  they  appear  in  PROUST’s  and  Micro-PROUST’s 
databases,  respectively. 

Input-Validation 

Form:  Input-Validation(.?V»\ ,  ?Pred) 

Name  phrase:  * input  validation  ' 

Main  component:  Guard: 

Instances:  BAD  INPUT  SKIP  GUARD 

BAD  INPUT  LOOP  GUARD 

Figure  7:  A  goal  in  PROUST’s  knowledge  base 
Input-Validation 

Name  phrase:  'input  validation' 

Instances:  BAD  INPUT  SKIP  GUARD 

BAD  INPUT  LOOP  GUARD 

Figure  8:  A  goal  in  Micro-PROUST’s  knowledge  base 

5.3.  Plans 

There  is  a  close  relationship  between  plans  in  Micro-PROUST  and  plans  in  PROUST.  Every 
plan  in  Micro-PROUST’s  knowledge  base  is  also  iD  PROUST’s  knowledge  base.  However, 
Micro-PROUSTs  plan  knowledge  contains  less  information  about  each  plan,  and  the  plans 
cannot  be  used  in  as  wide  a  range  of  cases  These  points  will  be  illustrated  via  a  specific 
example,  the  BAD  INPUT  LOOP  GUARD  PLAN,  which  is  an  implementation  of  the  goal 
Input-Validation.  This  plan  checks  input  data  for  validity,  and  repeatedly  rereads  the  data  until 
it  is  valid. 

Figure  9  shows  Micro-PROUST’s  version  of  the  BAD  INPUT  LOOP  GUARD  PLAN.  Like  all 
plans  in  Micro-PROUST  it  consists  of  Pascal  statements  to  match  against  the  program,  and 
pointers  indicating  where  the  plan  should  match.  The  Pascal  statements  consist  of  a  WHILE  loop 


containing  a  WRITELN  statement  and  a  READ  statement,  followed  by  an  IF  statement  testing  for  the 
sentinel  value.  The  pointer  indicating  where  to  match  the  plan  is  at  the  top  of  the  plan 
template;  it  indicates  that  the  plan  should  be  found  in  the  part  of  the  plan  implementing  the 
goal  Sentincl-Controlled-Input  which  is  labeled  Process:.  In  other  words,  the  plan  should  be  in 
the  part  of  the  loop  that  processes  the  input  data.  Note  that  this  plan  is  quite  specific;  it  will 
only  work  in  sentinel-controlled  loops,  and  even  then  it  will  not  match  if  a  READLN  statement 
appears  in  the  program  instead  of  a  READ  statement. 

BAD  INPUT  LOOP  GUARD 

Template: 

(in  component  Process:  of  goal  Sentincl-Controlled-Input ) 

Guard:  WHILE  ?Pred  DO 

BEGIN 

WRITELN (  ?*  ). 

Input:  READ(  ?Val  ) 

END; 

Interna  I  Guard :  IF  ?Val  <>  ?Stop  THEN 
Process:  ?* 

Figure  9:  MicroPROUST’s  BAD  INPUT  LOOP  GUARD  PLAN 

Figure  10  shows  PROUST’s  rendition  of  the  BAD  INPUT  LOOP  GUARD  PLAN.  The  main 
difference  between  the  two  plans  is  that  PROUST  allows  subgoals  to  be  inserted  into  the  plan. 
These  subgoals  become  part  of  the  goal  decomposition  that  PROUST  constructs  for  the 
program.  The  subgoals  can  be  implemented  using  different  plans,  thus  increasing  the  variety  of 
code  that  the  plan  can  match.  Instead  of  referring  specifically  to  the  goal 
Sentinel-Controlled-Inpvt  within  the  plan,  PROUST’s  plan  refers  to  a  generic  class  of  goals 
called  Read  &  Process.  This  class  denotes  all  goals  which  involve  the  inputing  and  processing  of 
data 

5.4.  Plan-difference  rules 

When  a  plan  fails  to  match  the  student’s  program  exactly,  the  differences  between  the  plan 
and  the  code  must  be  explained.  By  explaining  a  plan  difference  we  mean  suggesting  a  bug 
which  would  produce  the  detected  plan  difference,  as  well  as  misconceptions  which  can  cause  the 
bug  PROUST  and  Micro-PROUST  both  use  plan-difference  rules  to  explain  plan  differences. 
These  rules  are  test-action  pairs,  where  the  test  part  examines  the  plan  differences  and  the  action 
indicates  what  if  any  bugs  these  plan  differences  suggest.  There  is  a  correspondence  between 
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BAD  INPUT  LOOP  GUARD 

Variables:  ?Va  I ,  ?Pred 

Template: 

(in  component  Process :  of  goal  Read  &  Process ) 
spanned  by: 

Guard:  WHILE  ?Pred  DO 

BEGIN 

subgoal  Output  DiagnosticO 
Next:  subgoal  Simple  Input (?Val) 

END 

Process:  ?* 

Posterior  goals: 

Sentinel  Guard((? New  from  goal  Read  &  Process) . 

(?Stop  from  goal  Read  &  Process)) 

Figure  10:  A  plan  for  implementing  Input-Validation 

plan-difference  rules  in  the  two  systems,  although  the  tests  and  actions  of  the  rules  tend  to  differ 

in  certain  respects. 

To  see  how  plan-difference  rules  are  used  in  the  two  systems,  we  will  examine  how  they  explain 
one  of  the  bugs  in  the  example  in.  Figure  2.  This  program  uses  the  BAD  INPUT  LOOP  GUARD 
to  implement  the  goal  Input-Validation,  but  there  is  no  test  for  the  sentinel  value  after  the  WHILE 
loop  at  line  24.  PROUST  discovers  the  match  failure  when  it  is  processing  the  goal 
Sentinel-Guard,  a  subgoal  of  the  BAD  INPUT  LOOP  GUARD  PLAN.  The  plan-difference  rule 
which  accounts  for  the  jn&tch  failure  in  PROUST  is  shown  in  Figure  11.  The  rule  checks 
whether  the  sentinel  guard  is  the  only  plan  that  is  missing,  or  whether  the  input  step  is  also 
missing.  If  the  input  step  is  missing,  there  is  no  reason  to  complain  about  the  sentinel  guard 
being  missing,  since  the  missing  input  is  the  more  important  bug.  If  the  input  step  is  present, 
the  rule  checks  to  see  whether  there  are  sentinel  guards  elsewhere  in  the  loop  which  might  serve 
the  function  of  the  missing  sentinel  guard.  When  no  other  sentinel  guards  are  present,  the  rule 
indicates  that  the  missing  sentinel  guard  is  a  bug,  and  it  may  have  been  omitted  inadvertently 
by  the  student. 

IF  no  plans  implementing  Sentinel-Guard  can  be  matched, 

AND  the  input  step  of  either  BAD  INPUT  LOOP  GUARD  or  the 
main  loop  was  found. 

AND  no  sentinel  guards  appear  later  on  in  the  loop, 

THEN  the  sentinel  guard  may  have  been  omitted  by  mistake. 

Figure  11:  Rule  for  recognizing  missing  sentinel  guards 


Tbe  corresponding  rule  in  Micro-PROUST,  shown  in  Figure  12,  is  much  more  direct.  It  simply 

checks  to  see  whether  the  missing  plan  component  is  labeled  Interns  I  Guard : .  If  so,  it  may  have 

been  inadvertently  omitted  The  sentinel  guard  in  the  BAD  INPUT  LOOP  GUARD  PLAN  is 

labeled  Interna  I  Guard : ,  as  ran  be  seen  in  Figure  9.  Therefore  tbe  rule  applies.  Because 

Micro-PROUST’s  rule  is  simpler,  it  will  apply  in  6oroe  cases  where  it  should  not.  If  the  sentinel 

is  tested  in  an  unusual  but  correct  way,  Micro-PROUST  is  likely  to  indicate  that  the  sentinel 

test  is  buggy.  Micro-PROUST’s  rules  are  not  sensitive  to  correlations  between  bugs,  so  it  cannot 

detect  when  one  bug  might  be  the  cause  of  the  other. 

IF  a  plan  component  of  type  Interna IGuard :  cannot  be  matched, 

THEN  it  may  have  been  omitted  by  mistake. 

Figure  12:  Micro-PROUST’s  rule  for  missing  guards 

Some  plan-difference  rules  in  PROUST  not  only  explain  the  plan  differences;  they  also  correct 
them.  For  example,  rules  which  identify  when  BEGIN-END  pairs  are  missing  insert  the  missing 
BEGIN-END  pairs  into  PROUST’s  internal  parse-tree  representation  of  tbe  code.  Subsequent 
analysis  of  the  program  will  then  proceed  as  if  the  BEGIN-END  pairs  were  present  in  the  student’s 
program.  If  PROUST  did  not  insert  the  BEGIN-END  pairs,  it  might  misunderstand  the  intended 
data  flow  of  the  code,  and  signal  bugs  which  are  really  side-effects  of  the  buggy  block  structure. 
Micro-PROUST,  on  the  other  hand,  makes  no  attempt  to  correct  bugs.  It  therefore  is  more 
likely  to  signal  more  bugs  than  are  really  present  in  the  program. 

6.  Additional  Comparisons  of  PROUST  and  Micro-PROUST 

In  Figure  13  we  present  further  comparisons  of  PROUST  and  Micro-PROUST  along  a  number 
of  key  dimensions.  PROUST  has  been  under  development  for  some  4  years,  and  is  the  successor 
to  MENO,  an  earlier  version  of  our  bug  identification  system  [9].  In  contrast,  Micro-PROUST 
was  not  a  research  effort  but  could  draw  directly  on  our  experience  in  building  bug  analysis 
systems.  PROUST  is  faster  than  Micro-PROUST  as  long  as  enough  memory  is  available. 
However,  PROUST  needs  two  megabytes  of  memory  to  run  comfortably;  if  a  VAX  is  heavily 
loaded,  PROUST  slows  down  substantially,  and  Micro-PROUST  is  then  faster.  The  difference 
in  size  of  the  two  programs  is  dramatic;  Micro-PROUST  is  only  10%  of  tbe  size  of  PROUST!  In 
the  next  section,  we  address  the  natural  question:  can  Micro-PROUST  be  scaled  up  to  the  level 
of  PROUST’s  performance,  and  still  have  acceptable  time  and  space  characteristics? 
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PROUST 

Micro-PROUST 

Cost: 

~  $450,000 

~  $25,000 

Time: 

4  years 

2  months 

Coverage: 

2  programming 

assignments 

1  programming  assignment 

Bug  Catalogue: 

~  50  ~  10 

Size: 

15,000  lines  of  LISP 

1500  lines  of  LISP 

Machine: 

DEC  VAX  750  (4  Meg) 

IBM  PC  (512  K) 

Run  time: 

.5-3  minutes 

~90  seconds 

Performance: 

759c  of  bugs 

correctly  identified 

unknown 

Figure  13:  Fact  Sheet:  PROUST  and  Micro-PROUST 

7.  Scaling  Up  Micro-PROUST 

We  will  now  examine  some  of  the  issues  which  we  expect  will  arise  when  Micro-PROUST  is 
scaled  up  to  approximate  PROUST’s  performance  in  finding  bugs.  We  will  focus  on  two  issues: 
the  problems  involved  in  expanding  Micro-PROUST’s  knowledge  bases,  and  the  limitations  that 
Micro-PROUST’s  simplified  architecture  impose. 

In  order  for  Micro-PROUST  to  cover  a  wide  range  of  novice  programs,  its  knowledge  bases  will 
have  to  be  greatly  expanded.  In  PROUST,  4000  lines  of  code  are  needed  to  specify  goals,  plans, 
and  plan-difference  rules.  We  have  seen  that  Micro-PROUST’s  knowledge  bases  correspond 
closely  to  PROUST’s.  Since  Micro-PROUST’s  knowledge  is  simplified,  the  same  knowledge 
units  would  take  up  less  space  in  Micro-PROUST  than  they  would  in  PROUST.  On  the  other 
hand,  Micro-PROUST's  plans  are  not  as  general  as  PROUST’s,  since  they  cannot  contain 
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subgoals.  This  will  probably  mean  that  more  plans  will  have  to  be  added  to  Micro-PROUST 
than  appear  in  PROUST.  It  is  clear  that  Micro-PROUST’6  knowledge  bases  will  be  sizeable,  and 
will  press  against  the  space  limitations  of  the  IBM  PC. 

It  should  be  possible  to  organize  Micro-PROUST’s  knowledge  bases  so  that  space  limitations 
are  avoided.  Only  a  fraction  of  Micro-PROUST’s  knowledge  need  be  available  at  any  one  time. 
For  example,  when  a  particular  goal  is  being  processed,  the  only  plans  that  need  be  in  memory 
are  those  which  implement  that  goal.  It  therefore  should  be  possible  to  store  Micro-PROUST’s 
knowledge  on  disk,  and  retrieve  knowledge  only  as  needed.  Micro-PROUST’s  speed  would  be 
reduced  because  of  this,  so  it  is  hard  to  say  whether  the  resulting  system  would  be  fast  enough  to 
use  in  the  classroom. 

The  more  troubling  problems  with  Micro-PROUST  stem  from  the  reduced  power  of  its  analytic 
techniques.  Micro-PROUST  assumes  that  all  solutions  to  a  given  programming  problem  will 
have  the  same  goal  decomposition.  It  is  prone  to  misdiagnosis  of  novice  bugs.  These 
shortcomings  may  limit  Micro-PROUST’s  effectiveness,  or  may  necessitate  enhancements  of 
Micro-PROUST’s  diagnostic  capabilities. 

The  effect  of  restricting  the  goal  decompositions  of  programs  depends  on  the  complexity  of  the 
problem.  The  more  goals  there  are  that  must  be  satisfied  in  a  program,  the  more  ways  there  are 
that  these  goals  can  be  combined.  The  range  of  possible  goal  decompositions  therefore  increases 
rapidly  as  problem  complexity  increases.  Our  empirical  studies  of  novice  programs  indicate  that 
40%  of  novice  solutions  to  the  Rainfall  Problem  fail  to  conform  to  Micro-PROUST’s  goal 
decomposition  for  this  problem.  Micro-PROUST  cannot  avoid  making  frequent  analysis  errors 
as  long  as  its  model  of  students’  intentions  is  faulty  this  often. 

Even  if  Micro-PROUST’s  goal  decomposition  is  correct,  there  may  still  be  cases  where 
Micro-PROUST  misdiagnoses  bugs.  As  indicated  earlier,  Micro-PROUST  does  not  correct  bugs 
when  it  finds  them;  therefore  the  presence  of  some  bugs  may  cause  Micro-PROUST  to 
misdiagnose  other  bugs  Furthermore,  unlike  PROUST,  Micro-PROUST  has  no  way  of  choosing 
between  alternative  interpretations  of  the  code.  It  does  not  notice  if  more  than  one  plan  can 
match  the  same  lines  of  code.  Instead,  Micro-PROUST  simply  chooses  the  first  account  of  the 
code  that  it  comes  across.  Micro-PROUST’s  accuracy  will  sui/er  because  of  this,  but  the  extent 
of  the  performance  degradation  is  hard  to  predict.  Empirical  evaluations  of  Micro-PROUST  will 
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be  needed  to  determine  exactly  how  accurate  its  analysis  can  be  expected  to  be. 

8.  Concluding  Remarks 

As  a  demo,  Micro-PROUST  unquestionably  allows  one  to  quickly  see  the  potential  for 
computer-based  enhancement  of  learning.  However,  as  a  product,  it  is  still  unclear  whether  or 
not  Micro-PROUST  can  ever  be  even  approximately  as  effective  as  its  parent,  PROUST,  running 
on  a  large  machine.  However,  we  believe  that  Micro-PROUST’s  knowledge  can  be  expanded 
without  running  into  space  limitations.  The  resulting  system  should  be  reasonably  effective,  at 
least  on  simple  programming  problems  Further  work  will  be  required  to  determine  how 
effective  Micro-PROUST’s  approach  can  be,  and  whether  or  not  it  will  result  in  a  viable 
educational  tool. 
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5.  Micro-PROUST  Implementation:  The  LISP  Code 


Micro-PROUST  Code 


Page  12 


;.  there  ire  none  left  to  try 
(defun  plan-satch  (plans) 

(cond  ((null  plans)  ()) 

((ins-status  (ear  plans))  (plan-aatch  (edr  plans))) 

(t  (list-plan  (car  plans)) 

(cond 

((aatch-a-plan  (car  plans))  (car  plans)) 

(t  (plan-aatch  (edr  plans))))))) 

. ;  Recursively  try  to  aatch  each  line  of  the  plan  by  calling  aatch-coaponent. 

..  If  all  the  coaponents  aatch.  return  T.  else  block  the  plan  and  return  nil. 
(defun  aatch-a-plan  (plan) 

(cond  ((aatch-coaponent  plan  (ins-address  plan)) 

(and  eiec-out  (foraau  cheh-vindou  *T*I*)) 

(cond  ((equal  (incf  (ins-address  plan)) 

(length  (ins-aatches  plan))) 

(cond  (eiec-out 

(forint  t  **|Plan  *a  aatched  codel*  (ins-naae  plan)))) 
t) 

(t  (aatch-a-plan  plan)))) 

(t  (setf  (ins-status  plan)  t) 

(and  eiec-out 

(foraat  t  **|Natch  errors  in  plan  *a*  (ins-naae  plan))) 

()))) 

;;  Call  conteit-nodeset  to  get  a  list  of  possible  nodes  and  pass  this  list 
..  along  aith  the  plan  coaponent  to  irefer.  i label,  or  laatch.  depending  on 
..  vhat  type  of  antch  instractioa  it  is. 

(defua  aatch-coaponent  (plan  address) 

(let*  ((plan-line  (get-plan-eleaent  plan  address)) 

(nodeset  (conteit-nodeset  (caddr  plan-line)  plan))) 

(case  (car  plan-1  inn) 

((refer)  (irefer  plan-line  plan  address)) 

((label)  (ilabel  plan-line  plaa  address)) 

((aatch)  (laatch  plan-line  plaa  address))))) 

..  Get  the  pi  an- 1  me  for  aatch-coaponent 
(defun  get-plan-eleaent  (plan  address) 

(aref  (get  (ins-naae  plan)  'teaplate)  address)) 


Conteit-nodeset 


. ;  Conteit-nodeset  uses  the  third  arguaent  in  a  plan  coaponent  to  construct 
. .  a  list  of  nodes  ahich  can  be  aatched  The  third  argaaent  is  a  list  of  zero. 
:.  one.  or  tuo  eleaents.  Conteit-nodeset-1  creates  a  list  of  nodes  based  on 
.;  the  first  eleaent  if  it  eiists  and  conteit-nodeset-2  aodifies  this  list  of 
;.  nodes  based  on  the  secoad  eleaent  if  it  eiists  See  the  Spee  for  eleaent 
..  descriptions 

(defun  conteit-nodeset  (conteit  plan) 

(coateit-nodeset-2  (edr  conteit)  plan 

(conteit-nodeset-1  conteit  plaa))) 

..  Get  a  list  of  nodes  based  on  the  first  eleaent  of  the  conteit  descriptor 
..  or  return  the  list  of  the  highest  level  begin  block  for  a  null  coateit 
,  descriptor 

(defun  conteit-nodeset-1  (conteit  plan) 

(coed 

((null  conteit)  (get-begi e-block  (node-children  *perse-tree*))) 
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(and  eiec-out  (foraat  plan-uindou  •"l*a*  (aref  taplt  i))) 

(and  (aref  (ins-aatches  plan)  i) 

(and  eiec-ont  (foraat  chek-uindou  ■T*|*))))) 

(and  eiec-out  (any-key))) 

;;  List-goal  lists  the  goal  ease  in  the  goal-aiadoa. 

(defun  list-goal  (goal) 

(and  eiec-ont  (send  goal-aindoa  :clear-screen)) 

(and  eiec-out  (foraat  goal-aindoa  ■Current  Coal  Haae:  *a*  (car  goal))) 

(and  eiec-oat  (any-key))) 

. .  Any-key  prints  out  a  aessage  and  aaits  for  a  carriage  return  to  continue, 
(defun  any-key  () 

(cond  (eiec-out 

(foraat  eiec-aindoa  ■*lEnter  Carriage  Retura  to  Continue  — ■) 
(read-line  eiec-aindoa)) 

(t 

(foraat  t  **lEnter  Carriage  Return  to  Continue  — ■) 

(read-1 ine)))) 

Put  is  a  function  froa  older  lisps  that  I  ms  used  to  using. 

(defun  put  (i  y  z) 

(setf  (get  i  ))  i)) 

DPS  (varl  slotl  fill erl  slot2  fill er2  ...)  adds  properties  slotl.  slot2,etc. 
;;  to  the  property  list  of  varl.  It  is  used  to  baild  all  of  the  property 
. ;  I i sts . 

(defaacro  DPS  (varl  A body  slot-fill) 

(cond  ((oddp  (length  slot-fill)) 

(error  "DPS:  Bad  nuaber  of  arguaents*)) 

(t  (DPS1  varl  slot-fill)))) 

;;  Auiillary  function  to  DPS 
(defun  DPS1  (varl  slot-fill) 

(cond  ((null  slot-fill)  t) 

(t  (progn  ()  (put  varl  (car  slot-fill)  (cadr  slot-fill)) 
(DPS1  varl  (cddr  slot-fill)))))) 


:  Load  the  Hatch  group 

;;  Contains  the  fol losing  functions  and  their  supporting  functions: 

plan-aatch.  aatch-a-plan.  aatch-coaponent.  conteit-nodeset.  irefer, 
ilabel,  match,  get-candidates,  and  aatck-stat. 

. .  Hatch  sub-group  of  Hicro-Proust  HATCH2.lsp 

Written  by  Bret  Vallach  10/24/84 

;;  This  section  of  code  follous  the  Hicro-Proust  design  spec  fairly  uell. 

. .  Refer  to  it  for  further  details. 

Define  a  aatch-fraae 

(defstract  aatch-fraae 

(code  ()) 

(bindings  0) 

(errors  ())) 

High  level  Hatch  functions. 


Try  to  aatch  each  unblocked  (ins-status  is  ail)  plan  until  one  aatches  or 
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;;  nodes  so  the;  are  aot  aatched  again  later. 

(defun  close-goal  (goal  plan) 

(progn 

(push  (cons  goal  plan)  *analjrzed-goals*) 

(■ark-stats  plan))) 

;;  Hark  each  node  as  latched  unless  the  fourth  arguaeat  of  the  plan  line  is  T 
..  or  the  first  arguaent  is  a  Refer  or  Label  coaaand. 

(defun  aark-stats  (plan) 

(let*  ((taplt  (get  (ins-naae  plan)  ’teapiate)) 

(nodes  (ins-aatches  plan)) 

(n  (length  nodes))) 

(do* 

((i  0  (♦  .  1))) 

((*  i  n)) 

(cond  ((equal  (car  (aref  taplt  i))  ‘aatch) 

(setf  (node-aark  (car  (aref  aodes  i ) ) ) 

(not  (car  (cdddr  (aref  taplt  i)))))) 

(t  ()))))) 

. .  If  none  of  the  plans  uork  for  a  goal,  declare  it  aissing 
(defun  aissing-goal  (goal) 

(and  exec-out  (foreat  t  **|Coal  *a  is  aissing*  (ear  *active-goal*))) 

(setf  *bug-report*  (append  *bug-report*  (list  (list  (car  *actiue-goal*)))))) 


.  Report  the  bugs 


..  For  each  bug  call  report!  Reportl  deteraines  if  there  is  a  reporting 
..  function  defined  for  that  type  of  bug  and  calls  it  if  it  exists. 

(defua  report-bugs  () 

(foraat  t  *1*|  ••••***Bug  Report******  *) 

(■ape  •' reportl  *bug-rcport*) 

(foraat  t  ■*!*!  •••♦•End  of  Report*****1*c1*  12) 

t) 

..  The  car  of  a  bug  is  the  bug  naae  If  it  has  a  'report-fun  property. 

. .  retrieue  it  and  call  it  aith  the  rest  of  the  bug  as  an  arguaent.  See 
the  spec  for  details. 

(defun  reportl  (bug) 

(let  ((bug-func  (get  (ear  bug)  'report-fan))) 

(cond  (bug-func  (foraat  t  **|*I*) 

(fuacall  bug-func  (edr  bug))) 

(t  ())))) 


llti  I  ities 


::  List-plaa  lists  the  plaa  coaponeats  of  plaa  ia  the  plan-aiado*. 
(defun  list-plan  (plan) 

(and  eiec-out  (send  plan-uindoa  :clear-screen)) 

(and  euec-out  (send  chek-uindoa  :elesr-screen)) 

(and  euec-out  (foraat  plau-aiadoe  *Plaa-naae:  *a*  (ins-naae  plan))) 
(let*  ((taplt  (get  (ins-naae  plan)  ‘teapiate)) 

(nodes  (ins-aatches  plan)) 

(n  (length  nodes))) 

(do* 

((i  0  (♦  i  1))) 

((*  •  *)) 
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(process-next-goal) 

(cond  (e«*c-out 
(any-key) 

(send  'standard-output*  : set-size  80  25) 

(send  estandard-oatpete  : cl  ear-screen) 

(with-open-f i le 

(ous  prog  direction  :inpet  :eleauat-type  ‘stri ng-char) 
(pparse)))) 

(report-bugs)) 

Initialize  the  agenda 


Reads  the  problea  file  into  the  global  variable  ’agenda*.  Also  initializes 
*active-goals*.  *ana I y zed-goals*.  *bug-report* . 

(defun  mit-agenda  (problea) 

(progn 

(»ith-open-f i le 

(ous  problea 

direction  input  elcaent-type  'string-char) 

(setf  ‘agenda*  (read  oes))) 

(setf  *acti»e-goal*  ()) 

(setf  *analyzed-goals*  ()) 

(setf  *bug-report*  ()))) 


Process  the  goals 


;.  Pops  a  goal  off  the  top  of  *agenda*.  instantiates  the  goal,  processes  the 
goal  and  repeats  entil  there  are  no  goals  left.  It  also  call  list-goal 
;;  for  each  goal  which  lists  the  goal  and  bindings  in  goal  window. 

(defwn  process-neit-goal  () 

(cond 

(•agenda* 

(list-goal  (car  *agenda*)) 

(progn  (process-plans  (instantiate  (get-aeit-goal))) 

( process-ne i t-goa I ) ) ) 

(t  t))) 

;;  Pops  a  goal  off  the  top  of  *sgenda*. 

(defan  get-neit-goal  0 

(setf  *sctive-goal*  (pop  *agenda*))) 

;;  Processes  each  plan  returned  by  instantiate  entil  one  of  then  Batches  the 
;;  progrsa  code  or  none  of  thea  aatched  and  the  aisaatches  can't  be  eiplsiaed. 
(defun  process-plans  (plans) 

(let  ((good-plan  ())  (new-plans  plans)) 

(do  () 

((or  good-plan  (null  new-plans))) 

(setf  good-plan  (ptan-aatch  plans)) 

(cond  ((null  good-plan) 

(setf  new-plans  (eiplain-aisaatcles  plans})) 

(t  ()))) 

(cond  (good-plan  (close-goal  (ear  *active-goal*)  good-plan)) 

(t  (aissing-goal  *aeti ve-goa I •))))) 


Close  the  goal 


If  the  goal  had  a  plan  that  aatched.  reaeaber  it  and  aarh  all  the  aatched 
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Title-page 


Prints  title  page  in  beginning  of  progrta 
(defun  Title-page  0 
(foraat  t 

■IT* 

MICRO  PROUST 

A  PASCAL  Progreaaing  Tutor 


Oesigned  By: 

Elliot  Soloway  A  V.  Lewis  Johnson 
Yale  University 


Iepleaented  on  tke  IBM  PC  By: 

Brat  Mallaeh.  Advanced  Processing 
Leszek  Izdebski.  Courseware.  Inc. 

')) 

Parser  calling  functions 


. ;  Tkis  function  displays  tke  prograa  file  on  tke  screen  (using  pparse). 
and  parses  the  file  using  the  function  parse.  Dae  to  a  bug  in  CCLISP. 
I  was  unable  to  specify  a  larger  initial  stack  group.  As  a  result.  I 
create  a  special  stack  just  for  parsing. 

(defun  parse-call  (fileaaae) 

(foraat  t  ■'iLeaing  "a*  fileaaae) 

(with-open-f i la 

(ous  fileaaae  direction  : input  :eleaent-type  ’string-char) 
(pparse)) 

(stack-group-preset  *ne  ’parse  fileaaae) 

(foraat  t  •*|Parsing  "a*  fileaaae) 

(fwncal I  *n*  nil) 

(and  eiec-out  (any-key))) 

;;  Display  tke  prograa  oa  tke  screen. 

(defan  pparse  0 

(do  ((a  (read-line  ous  ()  t)  (read-line  ous  ()  t)) 

(i  1  (*  i  1))) 

((equal  a  t) ) 

(foraat  t  •'I'd  'a*  i  a))) 

(setf  *a*  (aake-stack-group  ’*ne  regvlar-pdl-size  3800 

:special-pdl-size  3800)) 


;;  Tkis  function  initialized  tke  goal  agenda,  processes  tke  goals,  and  reports 
.  the  errors  found . 

(defwn  aproust  (problea) 

(init-ageada  problea) 
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(any-key)) 

(t  (foraat  t  **|Unable  to  para*  filalTIf") 

(foraat  t  *"|Please  fii  syntax  errors  and  try  again.*) 
(any-key))))) 

(send  *standard-output*  : set-size  80  25) 

(do-qaestion)) 

(dribble) 

(e* it))) 

(defun  do-question  () 


(send  estaadard-output* 

.clear-screea) 

(foraat  t  "Your 

options 

are:*) 

(foraat  t  ■*! 

0: 

Run 

Proust 

Oft 

EX APPLE A  (average 

problea)*) 

(foraat  t  **l 

1: 

Run 

Proust 

Oft 

EXANPLE1  (average 

problea)*) 

(foraat  t  •*! 

2: 

Run 

Proust 

on 

EXARPLE2  (average 

problea)*) 

(foraat  t  **l 

3: 

Run 

Proust 

Oft 

EXARPLE3  (rainfall 

problea)*) 

(foraat  t  **| 

4: 

Run 

Proust 

Oft 

EXANPLE4  (rainfall 

problea)*) 

(foraat  t  *'J 

5: 

Run 

Proust 

on 

EXAMPLE5  (rainfall 

problea)*) 

(foraat  t  **X 
(exec-output) 

6: 

Run 

Proust 

Oft 

EXARPLER  (rainfall 

problea)*) 

(foraat  t  **l 

8 

Exit.*) 

(foraat  t  **fEnter  option:  ■)) 

(defun  eiec-output  () 

(cond  (eiec-out 

(foraat  t  *'|  7:  Disable  execution  output  (currently  enabled)*)) 

(t 

(foraat  t  *'l  7:  Enable  execution  output  (currently  disabled)*)))) 

;;  This  function  filters  out  reader  errors  that  uould  otheruise  cause  the 
prograa  to  boab. 

(defun  safe-read  () 

(sultiple-ualuc-bind  (uhat  err) 

(ignore-errors  (read)) 

(cond  ((null  err)  uhat) 

(t  (foraat  t  **|Input  error,  please  re-enter  "I*) 
(safe-read))))) 

;;  This  function  filters  out  reader  and  string  function  errors  that  uould 
;;  otheruise  cause  the  prograa  to  boab. 

(defun  safe-string-read  0 

(aultiple-value-bind  (uhat  err) 

(ignore-errors  (string  (read))) 

(cond  ((null  err)  uhat) 

(t  (foraat  t  **llnput  error,  please  re-enter. *!*) 
(safe-string-read))))) 

;;  This  function  filters  out  reader  and  string  function  errors  that  uould 
;;  otheruise  cause  the  prograa  to  boab. 

(defun  safe-p-read  () 

(aultiple-value-bind  (uhat  err) 

(ignore-errors  (read)) 

(cond  ((and  (null  err) 

(integerp  uhat) 

(>■  uhat  0) 

(<*  uhat  8)) 

uhat) 

(t  (foraat  t  **|lnpat  error,  please  re-enter. *1*) 
(safe-p-read))))) 


■1  l 
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1.3  MPROUST.LSP 

tttaproust. Isp 

;;  Aicro-PROUST  calling  functions  RPROUST.LSP 
;;  Written  bjr  Bret  Wslltck  of  Advanced  Processing  on  10/23/84 
for  Courseware.  Inc. 


;;  Welcose  to  Ricro-PROUST  Tkis  code  follows  tke  design  specification 
written  by  W.  Lewis  Johnson  fairly  well,  so  refer  to  tkat  Spec  wkea 
necessary 

;;  Authors  do  not  guarantee  tke  perforaaace  of  tkis  progrsa  in  any  way  nor 
;;  will  tkey  accept  responsibility  for  any  probleas  resulting  froa  tke  ase 
;  of  tkis  code. 

;;  This  is  the  top  level  function  It  sets  up  four  windows.  Eiee-window  is 
a  two  line  window  at  the  bottoa  of  tke  screen  used  by  any-key  to  wait  for 
..  a  <CR>  before  proceeding  Plan-window  contains  the  plan  currently  being 
;;  aatched.  chek-window  contains  a  T  for  each  coaponent  of  the  plan  that 
;;  aatched.  and  goal  window  contains  tke  current  goal  and  a  list  of  initial 
bindings  Tkis  function  asks  for  tke  prograa  file  end  a  problea  description 
;.  identifier  It  then  calls  parse-call  to  parse  tke  prograa  and  aproust  to 
;;  do  the  analysis  assuaing  it  was  possible  to  parse  tke  prograa. 

(defua  a-pronst  () 

(let  ((eiec-window  (aake-window-streaa  :top  23  :keigkt  2)) 

(plan-window  (aake-window-streaa  :top  12  :keigkt  11  : left  3)) 
(chek-window  (aake-window-streaa  :top  13  height  10  width  3)) 
(goal-window  (aake-window-streaa  top  ft  height  3))) 

(elose-al l-f i les) 

(send  *standard-output*  :clear-screee) 

(delete-file  (aerge-pathnaaes  'sysoet.dat*  ddeu)) 

;;  (dribble  (aerge-patknaaes  ■sysout  dat*  ddev)) 

(do-question) 

(do  ((p  (safe-p-read)  (safn-p-read))) 

((equal  p  8)) 

(coad  ((equal  p  7) 

(setf  ewee-out  (not  eiec-oat))) 

((and  (setf  prog  (car  (aref  efiles  p))) 

(setf  q  (cadr  (aref  efiles  p))) 

(eeltiple-vslee-bind  (ig  err) 

(ignore-errors  (close  (open  prog  :direction  : input))) 
err)) 

(foraat  t  *ffile  *a  not  found.*  prog) 

(any-key)) 

((awltiple-velee-biad  (ig  err) 

(ignore-errors  (close  (open  q  direction  : input))) 
err) 

(foraat  t  *~|file  "a  aot  found*  q) 

(any-key)) 

(t 

(perse-call  prog) 

(coed  (eparse-tree* 

(coad  (eiec-oat 

(send  estandard-output*  dear-screen) 

(send  *standard-output*  : set-size  80  8)) 

(t 

(foraat  t  **|Analyziag  prograa  for  errors  ..*))) 
(aproust  q) 
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(MULTIPLE-VALUE -BI1D 
(F  A  8  C  0} 

(ISYSINT  Mil  0  0  0  0) 

(1*  (LSH  (LOG AMO  A  MXOOCO)  6))) 


(WHEN  (OR  (MOT  (BOUNDP  ’ •MEMORY-ALLOCATED-P*) ) 

(MOT  *MEMORY-ALLOCATED-P»)) 

(ALLOCATE  M800  3.  2.  T)  :  allocate  all  OS  eea  bat  32K 

(SETQ  «MEMORY-ALLOCATEO-P*  T)) 

(load  *1  ispl  ibWdefaac  lap*) 

(load  *1 ispl ib\\defstr»ct  lap*) 

(LOAD  "I  ispl  ibWDRIBBLE  lap*)  ;  DRIBBLE  faaetioa 
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(IF  (PROBE-FILE  (FIRST  X)) 

(APPLY  ’OPEN  X) 

(PROG* 

(FORMAT  T  ■‘tlnsert  diskette  for  file  *A  it  drive  "A. 

Type  tty  cherecter  vken  ready." 

(NANESTRINC  (CAR  X)) 

(PATHNAME-DEVICE  (CAR  X))) 

(READ-CHAR) 

(APPLY  ’SAFE-FILE-OPEN  X)))) 

;;;  its  retker  ieportant  tket  tkis  is  HERE,  eot  iu to  loaded 
;;;  For  closing  ell  cvrreatly  open  files. 

(DEFUN  CLOSE-ALL-FILES  () 

(MAPCAR  '(LAMBDA  (FILE-STREAM) 

(PR0C1  (FILE-STREAM  PATHNAME) 

(FILE-STREAM  : CLOSE))) 

♦OPEN-FILE-STREAMS*)) 

(SETQ  ‘DEFAULT -PATHNAME -DEFAULTS*  (MERGE-PATHNAMES  (CD)  "FOO.LSP")) 


. .  THE  GCLISP  toplevel  kelp  facility 
(SETQ  *DEFAULT-IE-OPTIONS* 

’((IE-COMMANDS  (#\C-B  (LAMBDA  (WEST  IGNORE)  ;  TB  -  backtrace 

(TERPRI  T) 

(BACKTRACE) 

(TERPRI  T) 

REFRESH)) 

(•\C-D  .  (LAMBDA  (AREST  IGNORE)  ;  «ALT>-D  DOS 

(FORMAT  T  ""AGoing  to  DOS. . .") 

(DOS) 

REFRESH}) 

(•\C-G  .  (LAMBDA  (AREST  IGNORE)  ;  TO  -  CLEAN-UP-ERROR 

(CLEAN-UP-ERROR))) 

(«\C-L  (LAMBDA  (AREST  ICRORE)  .  TL  -  CLEAR  SCREEN 

(SEND  *TERNINAL-IO*  : CLEAR-SCREEN) 

REFRESH)) 

(•\C-P  (LAMBDA  (AREST  ICNORE)  ;  YP 

(CONTINUE))) 

(•\C-C  (LAMBDA  (AREST  IGNORE)  :  tZ 

(STACK-CROUP-UNWIND))) 

(#\ESC  .  (LAMBDA  (BUF  ICNORE) 

(LENGTH  BUF})) 

(•\RUBOUT  (LAMBDA  (IGNORE  IGNORE)  ;  <RUBOUT>  1  CHAR 

D) 

))) 

(DEFUN  FIND-FUNC  (BUF) 

(LET  ((IDX  (l-  (LENGTH  BUF)))) 

(WHEN  (PLUS?  IDX) 

(DOTIHES  (I  (LENCTH  BUF)) 

(IF  (EQ  #\(  (CHAR  BUF  IDX))  (RETURN  NIL)) 

(OCCF  IDX)) 

(READ-FROM-STRING  BUF  NIL  NIL  : START  (1*  IDX))))) 

(SETF  *SINCLE-DISKETTE-DRIVE-SYSTEN* 

(EQ  1  (UNLESS  *NUMBER-OF-DRIVES* 

(SETF  *NUMBER-OF -DRIVES* 
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((NULL  X)  (NRE VERSE  RESULT))))))) 

(88  ;8X 

(LANBOA  (S  IAUX  (*READ-BASE*  18.)) 

(READ  S  NIL  NIL  T))) 

(92  ;  #\ 

(LANBOA  (S) 

(FUNCALL  S  : UNTYI  92.)  ;  put  escape  ckar  back 

(00  ((STR  (STRINC  (READ  S  NIL  NIL  T))) 

(BITS  0) 

(I  0)) 

(0) 

(CONO  ((*  (-  (LENGTH  STR)  I)  1)  ;  1  ckar  left 

(RETURN  (CODE-CHAR  (CHAR  STR  I)  BITS))) 
((STRINC-EQUAL  »C-»  STR  START2  I  :END2  (♦12)) 

(SETQ  BITS  (LOGIOR  BITS  1) 

I  (♦  I  2))) 

((STRINC-EQUAL  •«-•  STR  START2  I  :END2  (♦  I  2)) 

(SETQ  BITS  (LOGIOR  BITS  2) 

I  (♦  I  2))) 

((NANE-CHAR  (SETQ  STR  (SUBSEQ  STR  I))) 

(RETURN  (CODE-CHAR  (NANE-CHAR  STR)  BITS))) 

(T 

(ERROR  "Bad  \*\i\\\»  aaae  *S*  STR)))))) 

(124.  ;#| 

(LANBDA  (S) 

(DO  ((CNT  0) 

(CHAR  (FUNCALL  S  :TTI)  (FUNCALL  S  :TYI>) 

(LCHAR  0  CHAR)) 

((AND  («  CHAR  35  )(•  LCHAR  124  H2ER0P  CNT))  NIL) 
(COND  ((AND  («  LCHAR  35.)(»  CHAR  124.)) 

(INCF  CNT)) 

((AND  (*  LCHAR  124. )(•  CHAR  35.)(>  CNT  0)) 

(DECF  CNT)))))) 

)) 

;  Used  by  tke  •♦  and  •-  aacros 
(DEFUN  If-FEATUREPI  (F) 

(COND  ((ATON  F) (MEMBER  F  ^FEATURES*)) 

((EQ  (CAR  F)  'NOT)  (NOT  ( |8-FEATUREP|  (SECOND  F)))) 

((EQ  (CAR  F)  ’OR) 

(DOLIST  (I  (REST  F)  NIL) 

(WHEN  (I9-FEATUREPI  I)  (RETURN  T)))) 

((EQ  (CAR  F)  'AND) 

(DOLIST  (I  (REST  F)  T) 

(UNLESS  (19-FEATUREPl  I)  (RETURN  NIL)))) 

(T  (ERROR  'Bad  •♦/-  feature  syatai:  *S*  F)))) 

(DEFUN  SHARP-NACRO  (STREAN  IGNORE  *AUX  X  Y) 

(SETQ  X 

(ASSOC  (CHAR-UPCASE  (SETQ  Y  (FUNCALL  STREAN  :TYI))) 
•SHARP-SIGN-NACROS*)) 

(IF  X 

(FUNCALL  (CDR  X)  STREAN) 

(ERROR  NIL  •Undefined  \8  aacro:  *C»  Y))) 

(SET-NACRO-CHARACTER  35.  'SHARP-NACRO) 

; :  A  SAFE  NAY  TO  OPEN  FILES 
(DEFUN  SAFE-FILE-OPEN  (WEST  X) 
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(IF  (NOT  (SYNBOtP  (NTH  2  FRN)))  FRN 
‘(NACRO  .(NTH  1  FRN)  (.(NTH  2.  FRN))  :  Naae  and  arglist 

(RPUCB  .(NTH  2.  FRN)  ;  Macro's  arg 

(PROCN 

pop  off  first  alaaaat  of  arg  list 
(SETQ  .(NTH  2.  FRN)  (COR  .(NTH  2.  FRN))) 

. NTHCDR  3  FRN))))))  ;  splica  ia  body 

;;  A  siaplt  DEFVAR  aacro 
(DEFHACRO  DEFVAR  FRN 
‘(UNLESS  (BOUNDP  '.(CAR  FRN)) 

(SETQ  .(CAR  FRN)  .(IF  (>  (LENCTH  FRN)  1.) 

(CADR  FRN) 

NIL)))) 

;;  A  siaple  DEFCONSTANT 
(DEFHACRO  DEFCONSTANT  FRN 
'(SETQ  .(CAR  FRN)  .(CADR  FRN))) 

A  siapei  DEFPARAHETER 
(DEFHACRO  DEFPARAHETER  FRN 
‘(SETQ  .(CAR  FRN)  .(CADR  FRN))) 

;;  The  Sharp  sign  aacro  character  handlers. 

(DEFCONSTANT  »SHARP-SICN-HACROS* 

'( 

(38  . 

(LAHBDA  (S) 

(LIST  'FUNCTION  (READ  S  NIL  NIL  T)))) 

(40  .  ;*( 

(LANBDA  (S  AAUX  X) 

(FUNCALL  S  UNTYI  40  ) 

(SETQ  X  (READ  S  NIL  NIL  T)) 

(APPLY  'VECTOR  X))) 

(43  .  ; 

(LANBDA  (S  AAUX  (X  (READ  S  NIL  NIL  T))) 

(VALUES  (READ  S  NIL  NIL  T)  (NOT  (|8-FEATUREP|  X))))) 

(45  ;  6- 

(LAHBDA  (S  AAUX  (X  (READ  S  NIL  NIL  T})) 

(VALUES  (READ  S  NIL  NIL  T)  (If-FEATUREPI  X)))) 

(46  ;  • 

(LAHBDA  (S) 

(EVAL  (READ  S  NIL  NIL  T)))) 

(58  . 

(LAHBDA  (S)  (COPY-SYHBOL  (READ  S  NIL  NIL  T)))) 

(66  ;6B 

(LANBDA  (S  AAUX  (*READ-BASE*  2.)) 

(READ  S  NIL  NIL  T))) 

(68  .  ;6D 

(LANBDA  (S  AAUX  (‘READ-BASE*  10.)) 

(READ  S  NIL  NIL  T))} 

(71.  ;60 

(LANBDA  (S  AAUX  (*RE AD-BASE*  8.)) 

(READ  S  NIL  NIL  T))) 

(83  ;6S 

(LANBDA  (S  AAUX  (SPEC  (READ  S  NIL  NIL  T))) 

(EVAL  (CONS  (INTERN  (STRINC-APPEND  *HAKE-*  (CAR  SPEC))) 

(DO  ((X  (CDR  SPEC)  (COON  X)) 

(RESULT  NIL  (CONS  ".(CADR  X)  (CONS  (CAR  X)  RESULT)))) 
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1.2  THEINIT.LSP 


ttttheinit.  Isp 

;;;  (C)  Copyright  Cold  Hill  Coapters.  a  Division  of  Apiary.  Inc.  1984 

GOLDEN  Coaaon  Lisp  initial ization  file 

(SETF  •NOHITOR-IS-COLOR*  NIL 

•SINCLE-DISKETTE-DRIVE-SYSTEA*  NIL 

♦NURBER-OF-DRI VES*  2 

•BREAK-EVENT*  ' (LAMBDA  (1AUX  INPUT -EDITOR) (BREAK))) 

(SETQ  • BQ-LEVEL*  0 

♦BQ-CORAA*  (CENSYN) 

•BQ-COAAA-AT*  (CENSYN)) 

;;  the  faaoes  back -quote  aacro 
(DEFUN  BQ  (X  AAUX) 

(COND  ((NULL  X)  NIL) 

((ATON  X)  (LIST  ’QUOTE  X)) 

( (EQ  (CAR  X)  •8Q-C0NRA*) 

(CADR  X)) 

(T 

(DO»  ((HOOK  (NCONS  ’LIST)) 

(Y  HOOK  (SNOC  Y  (BQ  (CAR  X)))) 

(X  X  (CDR  X))) 

((NULL  X)  HOOK) 

(COND  ((ATON  X) 

(RPLACA  HOOK  ’LIST*) 

(SNOC  Y  (LIST  ’QUOTE  X)) 

(RETURN  HOOK)) 

((EQ  (CAR  X)  •BQ-COHHA-AT*) 

(RPLACA  HOOK  ’LIST*) 

(RPLACD  Y  (NCONS  (LIST  ’APPEND 
(CADR  X) 

(BQ  (CDDR  X))))) 

(RETURN  HOOK}) 

((EQ  (CAR  X)  *BQ-CONNA*) 

(RPLACA  HOOK  ’LIST*) 

(RPLACD  Y  (NCONS  (CADR  X))) 

(RETURN  HOOK)))}))) 


(DEFUN  CORNA-HACRO  (STREAR  IGNORE  AAUX  X) 

(WEN  (<■  *8Q-LEVEL*  0) 

(ERROR  *Coaaa  not  inside  beckqeote*)) 

(IF  (OR  (EQ  (SETQ  X  (FUNCALL  STREAR  :TYI))  64.) 


(EQ  X  46)) 
•BQ-CORRA-AT* 

(FUNCALL  STREAR  UNTYI  X) 


is  it 

or  a  • 


;  pet  it  back 


(LIST  *8Q-C0RRA*  (READ  STREAR  NIL  NIL  T)))) 

(DEFUN  BQ-RACRO  (STREAR  IGNORE  AAUX  (*BQ-LEVEL*  (1*  • BQ-LEVEL*))) 
(BQ  (READ  STREAR  NIL  NIL  T))) 

(SET-RACRO-CHARACTER  44.  ’CORRA-RACRO) 

(SET-RACRO-CHARACTER  96.  ’BQ-RACRO) 

(AACRO  DEFNACRO  (FRR) 


I.  The  LISP  Code 


1.1  MPROUST.INI 

;;  Tttaproust.ini 
;  load  the  lisp  in  it  file 
(losd  •btheinitlsp*) 

;  default  drive 
(setf  ddev  *b:*) 

default  setting  for  executioa  output  flag 
(setf  eiec-out  t) 

;;  files 

(setf  efiles  ’#( 

(‘exaaplea  pas*  *averaga.prb*) 
(*exaaplel.pas*  ‘average. prb*) 
(*eiaaple2  pas*  ‘average. prb*) 
(*eiaaple3  .pas*  * ra i a f a  1 1  prb*) 
(*eiaaple4  pas*  'raiafal I .prb*) 
(*exaaple5.  pas*  *raiafal l.prb*) 
(■exaapler. pas*  *raiafal l.prb*) 

)) 


;;  aicro-proust  code  file 
(load  *b:f  i  lesWaprovst*) 


Micro-PROUST  Code 
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((equal  (eta r  context)  'at) 

(aref  (ins-natches  plan)  (-  (cadar  context)  1))) 

((equal  (caar  context)  ’containing) 

(get-ancestors  (list  (node-parent  (context-node  context  plan))))) 
((equal  (caar  context)  ‘above) 

(above  (context-node  context  plan) 

(node-children  (node-parent  (context-node  context  plan))))) 
((equal  (caar  context)  ‘below) 

(below  (context-node  context  plan) 

(node-children  (node-parent  (context-node  context  plan))))) 

(t  (get-begin-block  (node-children  eparse-tree*))))) 

Modify  the  node-list  based  on  the  second  eleaent  of  the  context  descriptor 
;  if  it  exists. 

(defun  context-nodeset-2  (context  plan  node-list) 

(cond 

((null  context)  node-list) 

((equal  (caar  context)  ‘top) 

(list  (car  (node-children  (enr  node-list))))) 

((equal  (caar  context)  ‘bottoa) 

(last  (node-children  (car  node-list)))) 

((equal  (caar  context)  ’above) 

(above  (context-node  context  plan)  (node-children  (car  node-list)))) 
((equal  (caar  context)  ’below) 

(below  (context-node  context  plan)  (node-children  (car  node-list)))) 
(t  node- I ist))) 


Context-nodeset  supporting  functions 


;;  Context-node  returns  the  list  of  nodes  located  in  ies-satebes  [context], 
(defun  context-node  (conteit  plan) 

(car  (aref  (ins-aatches  plan)  (-  (cadar  context)  1)))) 

;;  This  function  returns  all  of  the  siblings  in  Is  that  occur  above  the 
;;  stateaent  represented  by  node. 

(defun  above  (node  Is) 

(cond 

((null  Is)  0) 

((equal  (car  Is)  node)  ()) 

(t  (cons  (car  Is)  (above  node  (edr  Is)))))) 

;;  This  function  returns  all  of  the  siblings  in  Is  that  occur  below  the 
;;  stateaent  represented  by  node. 

(defun  below  (node  Is) 

(cond 

((null  Is)  ()) 

(t  (edr  (aeaber  node  Is))))) 

;;  This  function  returns  the  node  of  the  sain  begin  block  of  the  prograa 
(defun  get-begin-block  (nodes) 

(cond 

((null  nodes)  0) 

((equal  (node-naae  (car  nodes))  ’begin)  (list  (car  nodes))) 

(t  (get-begin-block  (edr  nodes))))) 


;;  This  function  returns  a  list  of  all  direct  ancestors  of  the  nodes  in  nodes. 

It  is  used  for  the  Containing  descriptor. 

(defun  get-ancestors  (nodes) 


Micro-PROUST  Code 


Page  14 


(cond 

((noli  (node-parent  (car  nodes)))  nodes) 

(t  (get-ancestors  (cons  (node-parent  (car  nodes))  nodes))))) 

Xaatch  functions 


;;  This  function  calls  get-candidates  to  aodify  the  nodeset  created  by 
■  Conteit-nodeset  end  call  oaatch-fraae  to  set-up  and  eiecute  a  aatch-stat. 
(defun  match  (plan-line  plan  address) 

(cond 

((equal  (cadr  plan-line)  ‘(*var*  *)) 

(setf  (ins-aatches  plan)  nodeset) 
t) 

(t 

(oaatch-f raae  (cedr  plan-line) 

(get-candidates  (caadr  plan-line) 

(caddr  plan-1  inn) 
nodeset) 

plan  address)))) 

This  function  creates  a  aatch  fraae  and  calls  aatch-stat  for  each  possible 
..  candidate  in  candidates  until  one  astehes  or  they  all  don't  Batch  The 
;;  aatch  fraae  for  each  candidate  the  doesn’t  aatch  is  pushed  onto  the 
, ;  partials  list  of  the  plan.  If  a  candidate  is  aatched,  thea  any  bindings 
accaaalated  during  the  aatching  process  are  added  to  the  plan  bindings 
(defan  aaatch-fraae  (pattern  candidates  plan  address) 

(cond 

((null  candidates) 

(setf  (ins-status  plan)  t) 

0) 

(t  (let  ((af  (aake-aatch-fraae))) 

(setf  (aatch-fraae-code  af)  (car  candidates)) 

(cond  ((aatch-stat  pattern  af) 

(setf  (aref  (ins-aatches  plan)  address) 

(list  (car  candidates))) 

(cond  ((aatch-frase-bindings  af) 

(setf  (ins-bindings  plan) 

(append  (aatch-fraae-bindiegs  af) 
(ins-bindings  plan))))) 
t) 

(t  (pash  af  (ins-partials  plan)) 

(aaatch-fraae  patters  (cdr  candidates) 

plan  address))))))) 


Cet  candidates  functions 


;;  Get-candidates  first  calls  aodify-aodeset  ahich  any  add  the  children  of 
;;  the  the  conteit-nodeset  to  nodes  depending  oa  the  eonteat  descriptor.  See 
;;  the  Spec  for  farther  details  Cet-cand-l iae  filters  oat  nodes  that  haae 
. .  already  been  narked  or  are  the  aroag  type  of  node. 

(defan  gat-candidates  (stat  des  sodas) 

(get-cand-t iae  (stat-table  stat)  (aodify-aodeset  des  nodes))) 

;;  This  function  returns  a  list  of  nodes  ehich  are  of  the  sane  stateaent  type 
;;  as  an  eleaent  of  stats  and  haae  not  been  narked  as  aatched 
(defan  get-cand-l i ae  (stats  nodes) 

(cond 
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((null  nodes)  ()) 

((and  (aeaber  (node-naae  (ear  nodes))  stats) 

(null  (node-sark  (car  nodes)))) 

(cons  (car  nodes)  (get-cand-l i ve  stats  (cdr  nodes)))) 

(t  (get-cand-l i ve  stats  (cdr  nodes))))) 

This  function  returns  a  list  of  stateaeats  vhich  are  siailar  or  identical  to 
;;  stat. 

(defan  stat-table  (stat) 

(or  (get  ‘s-table  stat)  (list  stat))) 

;;  Table  of  siailar  stateaeats 
(dps  s-table 
if  (if  while) 

■hile  (if  while) 
read  (read  :=) 

:«  (read  :=)) 

. .  This  function  returns  either  nodes  or  nodes  and  the  children  of  nodes 
;;  depending  on  des  (the  conteit  descriptor). 

(defun  sod i fy-nodeset  (des  nodes) 

(cond 

((and  (equal  (caar  des)  ’at) 

(or  (equal  (caadr  des)  'top) 

(equal  (caadr  des)  ’bottoa))) 

nodes) 

((equal  (caar  des)  'containing)  nodes) 

(t  (add-children  nodes)))) 

;;  This  function  returns  nodes  and  the  children  of  nodes 
(defun  add-children  (nodes) 

(cond 

((null  nodes)  ()) 

((atoa  nodes)  (cons  nodes  (add-children  (node-children  nodes)))) 

(t  (aapcaa  f 'add-chi Idrea  nodes))}) 

;;  Xlabel 


;;  This  function  set  ins-satches  of  the  current  plan  address  to  be  the 
;;  current  context-nodeset.  It  also  inserts  the  label  and  nodeset  into  the 
bindings  list  of  the  plan  so  it  can  be  refered  to  later  by  other  plans, 
(defun  xlabel  (plan-line  plan  address) 

(setf  (aref  (ins-satches  plan)  address)  nodeset) 

(push  (cons  (cadr  plan-line)  nodeset) 

(ins-bindings  plan)) 
t) 


Xrefer 


;;  This  function  retrieves  a  list  of  nodes  fros  the  bindings  list  of  analyzed 
;;  plans.  It  uses  the  second  eleseat  of  the  plan-line  as  the  label. 

(defua  xrefer  (plan-line  plan  address) 

(let  ((var 

(cond 

((null  (cdr  (cdadr  plaa-liae))) 

(cdr  (aapcaa  •'(laabds  (x)  (aeaber  (car  (cdadr  plan-line))  x)) 
(ins-bindings  plan)))) 
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t) 


(t  (resol ve-var-ref  (c»r  (cdsdr  plan-line)) 

(cadr  (cdadr  plan-1 me))))))) 

(setf  (aref  (ins-aatches  plan)  address) 

(coed  (var  ear) 

(t  (get-begi n-block  (aode-ch i Idree  ‘parse-tree*)))))) 


;  Aatch-stat 


..  This  feectioe  gets  the  aatchieg  started  by  calling  aatck-psreat 
(defee  aatch-stat  (pattern  a-fraae) 

(let  ((aatch-fraae  a-fraae)) 

(aatch-parent  pattern  (aatch-f raae-code  a-fraae)) 

(cond  ( (aatch-f raae-errors  a-fraae)  ()) 

(t  t)))) 

Natch-parent  calls  aatch-ch i Idren  for  the  childrea  of  the  carrent 
. ,  pattern  and  then  coapares  the  first  eleaent  of  the  pattern  aith  the 

. ;  node-naae  Note  that  «e  aust  atteapt  to  aatch  the  entire  pattern  even 

. .  if  there  is  a  a i snatch,  since  «e  hnve  to  coestract  a  coaplete  list  of 

;;  aisaatches  for  eiplaie-aisaatches  All  aisaa tches  are  added  to 

.  aatch-f raae-errors 
(defan  aatch-parent  (pattern  node) 

(let  ((bl  (aatch-ch i Idren  (cdr  pattern)  (node-children  node)))) 

(cond  ((not  (equal  (car  pattern)  (node-naae  node))) 

(push  (cons  (car  pattern)  (node-naae  node)) 

(aatch-f raae-errors  aatch-f raae) ) 

nil) 

(t  bl)))) 

;;  Rntch-chi Idren  tries  to  aatch  the  children.  Evan  if  there  is  a  aisaatch 
it  continues  on  to  try  and  find  Bore  aisaatches.  All  aisaatches  are  added 
;  to  aatch-f raae-errors.  See  the  Spec  for  aore  details. 

(defun  aatch-chi Idren  (pattern  node-list) 

(cond 

((and  (null  puttern)  (null  node-list))  t) 

((null  pattern) 

(push  (cons  0  (aapcar  'node-code  node-list)) 

(aatch-f rnae-errors  aatch-fraae)) 

ai  I) 

((equal  pattern  '((ever*  *)))  t) 

((null  node- list) 

(push  (cons  pattern  ()) 

(aatch-f  raae-errors  aatch-f  raae) ) 

ni  I) 

((atoa  (car  pattern)) 

(let  ((bl  (aatch-chi Idren  (cdr  pattern)  (cdr  node-list)))) 

(cond  ((not  (equal  (car  pattera)  (node-naae  (car  node-list)))) 
(push  (cons  (car  pattern)  (node-naae  (car  node-list))) 
(aatch-f  raae-errors  aatch-f  raae) ) 

ni  I) 

(t  bl)))) 

((equal  (car  pattern)  '(*vare  ?)) 

(aatch-chi Idren  (cdr  pattern)  (cdr  node-list))) 

((equal  (car  pattera)  ’(*vare  e)) 

(let  ((cur-bind  (copy-tree  (aatch-fraae-errors  aatch-fraae)))) 

(or  (aatch-chi Idren  (cdr  pattern)  (cdr  node-list)) 

(and  (setf  (aatch-fraae-errors  aatch-fraae)  car-bind) 
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nil) 

(aatch-ch i Idrea  (cdr  pattern)  node-list) 

(and  (setf  (aatch-f raae-errors  aatck-fraae)  cur-bind) 
nil) 

(aatck-cki Idrea  pnttarn  (cdr  node-list))))) 

((equal  (caar  pattern)  ‘eueru) 

(let  ((binds  (ckeck-bindings  (cndar  pattern))) 

(bool  1  (antck-cki Idrea  (cdr  pattern)  (cdr  node-1 ist)))) 

(cond  (binds 

(and  (aatck-cki Idren  (list  binds) 

(list  (ear  node-list))) 

booll)) 

(t  (add-bindings  (cndar  pattern) 

(node-code  (car  node-list))) 
(aatck-cki Idren  (cdr  pattern)  (cdr  node-list)))))) 
(t  (and  (aatch-parent  (car  pattern)  (car  node-list)) 

(aatck-cki Idren  (cdr  pattern)  (cdr  node-list)))))) 


Hatch  nti I ities 


;;  This  function  seraches  for  ear-ref  in  the  bindings  of  the  current  plan, 
and  the  bindings  of  the  aatck-fraae  and  returns  the  binding  if  found, 
(defun  check-bindings  (unr-rnf) 

(cond  ((equal  uar-ref  ’?)  ’?) 

((equal  uar-ref  ’•)  '?) 

(t  (or  (resol ue-uar  uar-ref 

(ins-bindings  plan)) 

(resolue-uar  uar-ref 

(aatch-f  raae-bi ad i ngs  aatck-f  raae) ) ) ) ) ) 

;;  Add  the  bindings  of  uar-naae  to  uar-ref  to  the  eurreat  aatck-fraae 
(defun  udd-bindings  (uar-ref  uar-naae) 

(push  (cons  uar-ref  uar-naae)  (aatck-fraae-bindings  aatck-fraae))) 

;;  Find  the  pair  (uar  .  bind)  in  the  a-list  list  and  return  bind. 

(defun  resolue-uar  (uar  list) 

(cdr  (assoc  uar  list))) 


;;  Load  the  Instantiate  group 

Contains  the  fol losing  functions  and  their  supporting  functions: 
Instnntiate,  Instantiate-plan,  Procesa-bindings-l ist,  and 
resol ue-unr-ref. 

;;  Instantiate  Sub-group  of  Hiero-Proust  IHS1. lap 
;;  Written  by  Bret  Valfack  10/24/84 

;;  Define  the  plan  instantiation  structure 
(def struct  ins 

(ease  ()) 

(bindings  ()) 
aatckes 
(partinls  0) 

(address  0) 

(states  0) 

(bugs  ())) 
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Instantiate 


This  function  returns  a  list  of  plaa  instantiations  for  the  plan 
'instances  of  the  goal.  The  bindings  list  of  the  goal  is  first  processed 
by  process-bi nd i ngs-l ist .  Iastaatiate-plaa  is  called  to  create  a  plaa 
instantiation  structure  for  each  plaa. 

(defun  instantiate  (goal) 

(let  ((bindings-l ist  (process-bi ad iags-l ist  goal))) 

(cond  (exec-out 

(foraat  goal-uindou  ■*l8indings:  •) 

(aapcar  'I  ins  bindings-l ist))) 

(setf  *acti ve-plans*  (aapcar  'iastaatiate-plaa 

(gat  (car  goat)  ‘instances))))) 

This  function  returns  either  the  the  binding  for  uariabte  bindings  or  the 
node-line  for  label  bindings.  This  is  used  to  display  a  aeaningful 
bindings  list  in  the  goal-aindo*. 

(defun  I  ins  (bin) 

(cond  ((atoa  (cdr  bin)) 

(foraat  goal-uindou  **a  “>  "a  •  (car  bin)  (cdr  bin))) 

((node-p  (cadr  bin)) 

(foraat  goal-uindou  ■*a  **>  line  *a  •  (car  bin)  (node-line  (cadr  bin)))) 
(t 

(foraat  goal-uindou  *”a  **>  "a  ■  (car  bin)  (cdr  bin))))) 


Process  the  bindings 


This  function  processes  the  bindings  list  of  goal  and  returns  the  bound 
bindings  by  calling  the  function  process-bi nd i ags-1 . 

(defun  process-bindings- I ist  (goal) 

(process-bi ndi ngs-l  (car  goal)  (cdr  goal))) 

This  function  calls  process-list  for  the  binding  specification  of  each 
eeaber  of  the  bindings  list.  It  conses  thee  all  together  and  ratums 
the  processed  bindings  list. 

(defaa  process-bi ndi ngs-l  (goal-naae  goal-list) 

(cond 

((null  goal-list)  ()) 

(t 

(cons  (cons  (caar  goal-1 ist) 

(process-list  goal-aaae  (cdar  goal-list))) 
(process-bi ndi ngs-l  goal-aaae  (cdr  goal-list)))))) 

This  function  substitutes  the  real  ualne  in  for  eaeh  (»uar»  x  y)  triple 
in  the  I ist  usr-ual 

(cefun  process-list  (goal-naae  uar-ual) 

(cond 

((null  uar-ual)  ()) 

((atoa  uar-ual)  uar-ual) 

((equal  (ear  uar-ual)  'euare) 

(resol ue-uar-ref  (cadr  uar-ual)  (csddr  uar-ual))) 

(t(coas  (process-list  goal-aaae  (car  uar-ual)) 

(process-list  goal-aaae  (cdr  uar-ual)))))) 

This  function  returns  the  uslue  of  earl  which  was  bound  in  goal. 

(defun  resol ue-uar-ref  (uarl  goal) 
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(let  ((inst  (resolve-var  goat  *analyzed-goals*))) 

(coed  ((eel  I  iest)  0) 

(t  (resolve-var  earl  (ins-bindings  inst)))))) 

This  function  returns  a  plan  instantiation  struetare  for  plan 
(defun  instantiate-plen  (plan) 

(eake-ins  naaa  plan 

bindings  bindings-l ist 

aatches  (sake-array  (length  (get  plan  ’teaplate)) 
: iaitial-eleaeat  ()))) 

Utility  to  display  a  plan  instantiation  structure 
(defun  list-ins  (plan) 

(print  (ins-naae  plan)) 

(print  (ins-bindings  plan)) 

(print  (ins-aatches  plan)) 

(print  (ms-partials  plan)) 

(print  (ins-address  plan)) 

(print  (ms-status  plan)) 

(ms-bugs  plan)) 


;;  Load  the  goal  k non  I  edge  base 

;;  Goal  Knouledge  Base  for  Nicro-Proust  GOALS. kbs 

;;  Taken  directly  froa  Nicro-Proust  Design  Spec  10/23/84 

. ,  INSTANCES  refer  to  possible  plan  aaaus. 

;;  NANE-PHRASE  describes  uhat  the  goal  is  doiag.  This  is  used  during 
;;  bug  reporting 

(DPS  SENTINEL-CONTROLLED-LOOP 

INSTANCES  (SENTINEL-READ-PROCESS-WHILE 
SENTINEL-PROCESS-RE AD-WHILE 
SENTINEL-READ-PROCESS-REPEAT) 

NANE-PHRASE  ■ input  processing*) 

(DPS  LOOP-INPUT-VALIDATION 

INSTANCES  (BAD-INPUT-SKIP-CUARD 
BAD-INPUT -LOOP-CUARD) 

NANE-PHRASE  'input  validation*) 

(DPS  AVERAGE 

INSTANCES  (AVERACE-PLAN) 

NANE-PHRASE  'average*) 

(DPS  OUTPUT 

INSTANCES  (WRITELN-PLAN) 

NANE-PHRASE  ‘output*) 

(OPS  COUNT 

INSTANCES  (COUNTER-PLAN) 

NANE-PHRASE  'count*) 

(DPS  SUN 

INSTANCES  (RUNNING-TOTAL) 

NANE-PHRASE  *sea*) 

(DPS  GUARDED-COUNT 


.-y 


..**  a  m  •  ^  ***  to  "  »  *  *  m  *  to  "  *  a  *  t "".to  **  "  *  *  *  "k/*  "  *  *  <•  *  a  "a  *  *  /  W*  J*  •  ,  • %  *  »j| 
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INSTANCES  (CUARDED-COUNTER-PtAN) 
NANE-PHRASE  •count*) 

(OPS  NAXINUN 

INSTANCES  (NAXINUH-PLAN) 

NANE-PHRASE  •■•« ione*) 

(OPS  CUARO-E  XCEPT ION 

INSTANCES  (CUARO-EXCEPTION-PtAN) 
NANE-PHRASE  ‘boundary  conditio*  cheek*) 


. .  Lond  the  plnns 

. ;  Pin*  knowledge  bnse  for  Hicro-Pronst  PLANS. kbs 

;;  Take*  fron  Nicro-Proust  design  spec  with  soee  nod i f icatio* . 

, ,  A  fonrth  elenent  has  bee*  added  to  soae  lines.  If  tkis  elesent  is  T. 

;;  the*  the  node  which  the  statement  Batches  is  lot  Barked  as  beiag  Batched. 

..  If  it  is  nil  or  non-existent.  the*  the  Batched  node  is  Barked.  Tkis 
is  onljr  valid  for  NATCH  instrsctions. 

. ,  Sob*  of  the  context  descriptor  line  nwabers  were  in  error  i*  the  Spec 
;;  and  are  fixed  in  this  file. 

(OPS  SENTINEL-PROCESS-READ-NHILE 
TENPLATE 

•((NATCH  (WHILE  (<»  (*VARe  NEW)  (*VAR*  STOP))  (aVARn  ?))  ()) 

(LABEL  NAINLOOP  ((AT  I))) 

(NATCH  (BECIN  (aVARa  •))  ((AT  1))) 

(HATCH  (READ  (aVARa  NEW))  ((AT  3)  (BOTTON))) 

(LABEL  NEXT  ((AT  4))) 

(LABEL  PROCESS  ((AT  3)  (ABOVE  5))) 

(NATCH  (READ  (aVARa  NEW))  ((ABOVE  1))) 

(LABEL  INIT :  ((AT  7))))) 

(DPS  SENTINEL-READ-PROCESS-WHILE 
TENPLATE 

•((NATCH  (WHILE  (<>  (aVARa  NEW)  (eVARa  STOP))  (aVARa  T))  ()) 

(LABEL  NAINLOOP  ((AT  1))) 

(NATCH  (BECIN  (aVAR*  a))  ((AT  1))) 

(NATCH  (READ  (aVARa  NEW))  ((AT  3)  (TOP))) 

(LABEL  NEXT  ((AT  «))) 

(HATCH  (IF  (<>  (aVARa  NEW)  (aVARa  STOP))  (aVARa  T))  ((AT  3)  (BELOW  4))) 
(LABEL  PROCESS  ((AT  6))) 

(LABEL  INTERNAL-CUARD:  ((AT  6))) 

(N»  CM  (a  (aVARa  NEW)  (aVARa  SEEDVAL))  ((ABOVE  I))) 

(LA"EL  INIT:  ((AT  •))))) 

(OPS  SENTINEL-RE AO- PROCESS-RE PE AT 
TENPLATE 

•((NATCH  (REPEAT  (aVARa  ?)  (■  (aVARa  NEW)  (aVARa  STOP)))  0) 

(LABEL  NAINLOOP:  ((AT  1))) 

(NATCH  (STATENENT-LIST  (aVARa  a))  ((AT  1))) 

(NATCH  (RE AO  (aVARa  NEW))  ((AT  3))) 

(LABEL  NEXT  ((AT  4))) 

(NATCH  (IF  (<>  (aVARa  NEW)  (aVARa  STOP))  (aVARa  7))  ((AT  3)  (BELOV  4))) 
(LABEL  PROCESS  ((AT  «))))) 
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;;  (LABEL  PROCESS  :)  Has  ckangad  froa  ((AT  2))  to  ((AT  3))  so  as  to 
;;  avoid  a  conflict  betveen  TEST:  and  PROCESS:  daring  tka  eiptaia 
::  aissiag  ruins  functions. 

(OPS  8 AD-IHPUT-SK I P-CUARO 
TERPLATE 

•  ((REFER  (»VAR»  PROCESS:  SERTIHEL-COHTROLLED-LOOP)  ()) 

(BATCH  (IF  (*VAR*  PREO)  (*VAR»  ?)  («VARn  ?))  ((AT  1))) 

(LABEL  TEST:  ((AT  2))) 

(NATCH  (WRITELN  (*VAR*  •))  ((AT  2))) 

(LABEL  PROCESS:  ((AT  3))))) 

(DPS  BAD-INPUT-LOOP-CUARD 
TERPLATE 

•((REFER  (*VAR»  PROCESS:  SERTIHEL-COHTROLLED-LOOP)  {)) 

(HATCH  (WHILE  (»VAR«  PRED)  («VARa  ?))  ((TOP)  (AT  1))) 

(LABEL  TEST:  ((AT  2))) 

(NATCH  (BECIN  (*VAR*  •))  ((AT  2))) 

(HATCH  (WRITELN  («VAR*  •))  ((AT  4))) 

(NATCH  (READ  (*VAR*  NEW)}  ((AT  4)  (BELOW  5))) 

(LABEL  INPUT  ((AT  6))) 

(NATCH  (IF  (<>  (»VAR«  NEW)  (»VARa  STOP))  (*VAR*  •))  ((AT  1) (BELOW  2))) 
(LABEL  PROCESS  ((AT  8))))) 

(DPS  AVERACE-PLAR 
TERPLATE 

•((REFER  (*VAR*  HAIRLOOP:  SENTIREL-CORTROLLED-LOOP)  ()) 

(NATCH  (:■  (»VAR»  AVC)  (/  (‘VAR*  SUN)  («VARn  COURT)))  ((BELOW  1))) 
(LABEL  UPDATE  ((AT  2))))) 

(DPS  WRITELN-PLAH 
TERPLATE 

•  ((HATCH  (WRITELR  («VAR*  •)  (*VAR*  VAL)  (»VARa  •))  0) 

(LABEL  OUTPUT:  ((AT  1))))) 

(DPS  COUHTER-PLAH 
TERPLATE 

•((REFER  (aVARa  PROCESS:  SENTIREL-CORTROLLED-LOOP)  0) 

(NATCH  (:«  (aVARa  COURT)  (*  (nVARn  COURT)  1))  ((AT  1))) 

(LABEL  UPDATE:  ((AT  2))) 

(REFER  (*VAR*  HAIRLOOP:  SENTIREL-CORTROLLED-LOOP)  ()) 

(NATCH  (:«  (*VAR*  COUNT)  0)  ((ABOVE  4))) 

(LABEL  IRIT :  ((AT  5))))) 

(DPS  CUARDED-COURTER-PLAR 
TERPLATE 

•  ((REFER  («VARn  PROCESS  SENTIREL-CORTROLLED-LOOP)  0) 

(HATCH  (IF  (*VAR«  PREO)  («VAR*  ?))  ((AT  I))) 

(LABEL  CUARD  ((AT  2))) 

(NATCH  (:»  (»VARn  COURT)  (♦  (*VAR*  COURT)  1))  ((AT  3))) 

(LABEL  UPDATE:  ((AT  4))) 

(REFER  (*VAR*  HAIRLOOP:  SENTIREL-CORTROLLED-LOOP)  ()) 

(NATCH  (  >  (*VAR*  COURT)  0)  ((ABOVE  6))} 

(LABEL  IRIT:  ((AT  7))))) 

(DPS  RURRIRC-TOTAL 
TERPLATE 

•((REFER  (»VARa  PROCESS:  SENTIREL-CORTROLLED-LOOP)  0) 

(NATCH  (:«  (*VAR»  TOTAL)  (♦  (*VAR«  TOTAL)  (*VARa  NEW)))  ((AT  1))) 
(LABEL  UPDATE :  {(AT  2))) 
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(REFER  (*VAR»  RAINLOOP:  SENTINEL-CONTROLLED-LOOP)  0) 
(NATCH  (:■  (.VAR*  TOTAL)  0)  ((ABOVE  4))) 

(LABEL  INI T :  ((AT  S))))) 


. .  This  pit*  is  mstd  up.  but  works  seff  iciently  for  ton. 

. .  Both  LABEL  statements  have  been  added  for  bag  rate  purposes. 

. .  Problems  are : 

1  It  mitt  match  IF  count  *  0  then  ave  *  sum  /  count  else  mritela  ('a') 
This  is  clearly  backmards. 

2  Usually  uhea  the  IF  statement  is  missing,  the  VRITELN  statement  is 
missing  also  Therefore,  bug  rules  explain  the  missing  IF.  adding 
something  to  *bug-report* .  Then  the  VRITELN  is  also  not  matched 
and  more  bug  rules  fire  uhich  should  generate  another  error  message 
Tuo  messages  for  one  error  is  tuo  much. 

(DPS  CUARD-EXCEPT ION-PLAN 
TENPLATE 

•((REFER  (»VAR*  CODE)  ()) 

(NATCH  (IF  (*VAR»  PRED)  (»VAR»  ?)  (»VAR»  ?))  ((CONTAINING  1))  T) 
(LABEL  EXCEPTION:  ((AT  2))) 

(NATCH  (VRITELN  (»VAR»  •))  ((AT  3))  T) 

(LABEL  GUARD-ACTION  ((AT  4))))) 

(DPS  NAXINUN-PLAN 
TENPLATE 

•((REFER  (*VAR.  PROCESS:  SENTINEL-CONTROLLED-LOOP)  0) 

(NATCH  (IF  (>  (uVARu  NEW)  (»VARn  RAX))  (nVAR*  T))  ((AT  1))) 

(NATCH  (:«  (*VAR.  NAX)  (nVARe  NEV))  ((AT  2))) 

(LABEL  UPDATE  ((AT  3))) 

(REFER  (.VAR*  RAINLOOP  SENTINEL-CONTROLLED-LOOP)  (» 

(NATCH  (  :«  (*VAR*  NAX)  (*VAR*  NINVAL))  ((ABOVE  5))))) 


Load  the  Pars*  group 

Contains  the  following  functions  and  their  supporting  functions: 

Pars* 

Leu-initial ize  and  Lev-gottok  are  not  used.  See  parse. Isp  for  further 
detai Is. 

Pars*  sub-group  of  NPROUST  PARSE  LSP 
Written  by  Bret  Hal  lack  10/24/84 

Only  one  week  was  allocated  for  the  Parser  and  Lever  and  there 
were  no  compiler  compilers  or  other  such  tools  available.  As 
a  result  this  is  on*  of  the  more  slow,  inefficient,  and  klmdgy 
parser/levers  in  evistanc*  today.  Hell,  enough  for  excuses. 


;;  This  function  uses  read-tokens  to  get  s  list  of  tokens  and  their  lias 
;.  numbers  from  the  program  file.  It  then  makes  as  array  oat  tbs  list 
;;  and  stuffs  it  in  the  global  variable  sentence.  The  global  variable 
;;  s-ptr  points  to  the  current  token  in  sentence.  The  fenction  p-natch 
. .  is  then  called  to  beild  the  pars*  tree  from  the  tokens. 

(defea  pars*  (filename) 

(let*  ((.I ine-neaber*  1) 

(v  (read-tokens  filename)) 

(sentence  (make-array  (♦  (length  v)  2)  : f i I l-pointer  0)) 

(s-ptr  0)) 
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(wapcar  I'Oaabda  (z)  (*«cU>',-f  .sk  i  sentence))  i) 
(vector-push  ‘(nit  0)  sentence) 

(vector-push  ‘(*'1  0)  ikIiici) 

(setf  *parse-tree*  (cir  ip-aatch  ’*progrea))))) 


The  laiar 


;;  Unfortunate  I  jr  for  aa.  CCLISP  version  0  98  ka*  a  bag  aakiag  it  iapossible 
;;  to  restore  the  read  table  after  alteriag  it  to  defiae  various  characters 
;;  sack  as  ♦  to  be  aacro  characters.  As  a  resalt.  I  had  to  trite  a;  oaa 
. ;  read  faactioa. 

;;  Read-tokens  opens  the  prograa  file  and  calls  read-tokens-1  to  work  on  it 
(defun  read-tokens  (filenaae) 

(with-open-f i le 

(ous  filenaae  :directioa  inpat  :eleaeat-tjrpe  ’string-char) 
(read-tokens-1))) 

;;  Read-tokens-1  creates  a  list  of  conses  (sjrabol  .  *1 ine-auaber*)  where 
::  sjrabol  is  gotten  by  calling  rend-pas  and  •!  ine-nuaber*  is  the  current 
;  line  in  the  file 
(defun  read-tokens-1  () 

(do*  ((sjrab  (read-pas  ous  ()  ())  (read-pas  oas  ()  ())) 

(es  (list  (cons  sjrab  *1  ine-naaber*)) 

(append  cs  (list  (cons  sjrab  *1  ine-naaber*))))) 

((equal  sjrab  ())  cs))) 

;;  Read-pas  reads  characters  until  it  hits  a  aacro-character.  It  than  calls 
;;  Read-pasl  to  process  it. 

(defun  read-pas  (streaa  eof-f  eof-r) 

(setf  (fill-pointer  read-aector)  0) 

(do  ((tchar  (read-char  streaa  eof-f  aof-r) 

(read-char  streaa  eof-f  eof-r))) 

((assoc  tchar  break-alist)  (read-pasl  tchar)) 

(vector-push  tchar  read- vector))) 

;;  Read-pasl  either  returns  the  sjrabol  just  read  or  processes  the  aacro  char, 
(defun  read-pasl  (tchar) 

(cond  ((equal  (fill-pointer  read-vector)  0) 

(funcall  (cdr  (assoc  tchar  break-alist))  tchar)) 

(t 

(unread-char  tchar  streaa) 

(read-froe-string  read-vector)))) 

;;  This  arrajr  is  used  to  build  the  sjrabols 

(setf  read-vector  (aake-arrajr  258  t leeent-tjrp*  'string-char  :f ill-pointer  0)) 

;;  This  a- list  contains  all  the  special  characters 

(setf  break-alist  *((9\  .  ign)  (13  .  ign)  (9  .  ign)  (12  .  ign) 

(10  .  Ip)  (9\*  .  rea)  (ail  .  endfan)  (#\{  .  coa) 

(#\.  .  rea)  (0\(  .  par)  (9\)  .  rea) 

(8\-  .  rea)  (9\;  .  rea)  (9V  .  dq) 

(9\*  .  rea)  (8V  .  rea)  (9\*  .  rea) 

(8\<  rea)  (8\>  .  rea)  (#\:  .  rea))) 

.  Character  aacros 


I CD  ignores  the  character.  It  is  used  for  spaces,  tabs,  etc. 
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(defun  iga  (ckar) 

(do  ((«  (read-char  streaa  eof-f  eof-r) 

(read-char  streaa  eof-f  eof-r))) 

((aot  (equal  i  char)) 

(proga  (uaread-char  i  streaa) 

(read-pas  streaa  eof-f  eof-r))))) 

;;  Lp  is  called  for  a  line-feed  It  iaereaeats  *1 iae-auaber* 

(defua  Ip  (char)  (iacf  • I i ae-auaber*)  (read-pas  streaa  eof-f  eof-r)) 

Rea  returas  the  read  character 
(defua  rea  (char)  (vector-push  #\\  read-vector) 

(vector-push  char  read-vector) 

(read-froa-striag  read-vector)) 

Par  is  the  left-pareathesis  aacro  If  a  *  follows  iaaediateljr  thea 
..  igaore  everything  until  •)  since  it  is  a  coaaeat.  Otherwise  return  ’\( 

(defua  par  (char) 

(let  ((a-char  (read-char  streaa  eof-f  eof-r))) 

(coad  ((equal  n-char  l\») 

(do*  ((ch  i\(  s) 

(*  (read-char  streaa  eof-f  eof-r) 

(read-char  streaa  eof-f  eof-r))) 

((or  (and  (equal  a-char  #\*)  (equal  i  #\))) 

(equal  1  eof-r)) 

(read-pas  streaa  eof-f  eof-r)))) 

(t  (uaread-char  a-ckar  streaa) 

(vector-push  #\\  read- vector) 

(vector-push  i\(  read-vector) 

(read-froa-striag  rasd-vector))))) 

Coa  is  the  {  aacro.  Ignore  the  coaaeat 
(defua  com  (char) 

(do  ((i  (read-char  streaa  eof-f  eof-r)  (read-char  streaa  eof-f  eof-r))) 
((or  (equal  i  #\})  (equal  a  eof-r))  (resd-pas  streaa  eof-f  eof-r)))) 

Dq  is  the  single-quote  aacro.  It  turns  the  *  into  ■  sad  returns  a  string, 
(defun  dq  (ckar) 

(vector-push  $\m  read-vector) 

(do  ((i  (read-char  streaa  eof-f  eof-r)  (read-char  streaa  eof-f  eof-r))) 

((or  (equal  i  #V)  (equal  i  eof-r)) 

(proga  (vector-push  #\*  read-vector) 

(decf  (fill-pointer  read-vector)) 

(vector-push  i\*  read-vector) 

(read-froa-striag  read-vec*or))) 

(vector-push  ■  read-vector))) 

;;  Endfun  returns  ()  signifying  the  end  of  the  file. 

(defun  endfua  (ckar)  eof-r) 

;;  Parse  functions 


;;  Define  a  parse-tree  node 
(defstruct  node 
(ease  ()) 

(parent  ()) 
(children  ()) 

(line  0) 

(asrk  ())) 
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.  Debug  Util  it;  to  list  the  node  inforaatiou 
(defua  list-node  (i) 

(print  (node-naae  i)) 

(print  (code-parent  i)) 

(print  (node-children  i)) 

(print  (node-1  ine  0) 

(node-nark  ■)) 

. .  Debug  Utility  to  get  the  parenthesized  PASCAL  starting  at  parse  node  t. 
(defun  node-code  (0 
(cond  ((null  x)  0) 

((null  (node-children  x))  (node-naae  x)) 

(t  (cons  (node-naae  x)  (aapear  ‘node-code  (node-children  x)))))) 


.Parse  antching 


..  This  is  the  starting  parse  aatcher.  It  uses  the  global  variable  sentence 
and  aatches  it  to  the  EBNf  specified  by  g-aede.  If  g-node  has  no  ‘teaplate 
. .  property  and  g-node  is  equal  to  the  current  token  in  sentence,  then  create 
..  a  neu  node  uith  naae  g-node  and  return  If  g-aode  has  a  teaplate  thee 
call  p-aatch-1  uith  the  teaplate  and  try  to  aatch  the  teaplate  against 
..  the  sentence  If  the  aatch  succeeds  p-aatch-1  ail  I  return  a  list  of 
..  children  nodes  If  the  ‘parent  property  of  g-node  is  nil.  return  that 
.;  list  of  children,  otheruise  create  a  aeu  node  uith  those  children 
..  Otheruise  return  nil 
(defun  p-aatch  (g-node) 

(let  ( (tpl t  (get  g-node  ‘teaplate)) 

(par-naac  (get  g-node  ’parent)) 

(c-nodc  ()) 

(line  1) 

(pur  ())) 

(cond  ((null  tplt) 

(cond  ((equal  g-node  (car  (aref  sentence  s-ptr))) 

(incf  s-ptr) 

(list  (sake-node  naae  g-node 

line  (edr  (aref  sentence  s-ptr))))) 

(t  ()))) 

(t  (and  (setf  line  (edr  (aref  sentence  s-ptr)) 
c-node  (p-aatch-1  tplt)) 

(coad  ((and  par-naae  (not  (eq  c-node  t))) 

(setq  par  (aake-node  naae  (get  g-node  ’parent) 
children  c-node 
line  line)) 

(aapear  •’(laabda  (x) 

(setf  (node-parent  x)  par)) 

c-node) 

(list  par)) 

(par-naae 

(list  (aake-node  aaaa  (get  g-node  ’parent) 
line  line))) 

(t  c-node))))))) 

. ;  This  function  tries  to  aatch  each  option  of  a  teaplate  uith  the  sentence 
..  tokens  pointed  to  by  s-ptr.  If  eay  of  thea  aatch,  return  the  children 
;.  created  in  the  process,  else  return  nil. 

(defun  p-aatch-1  (taplt  Aaux  chi  I  bool  1  s-ptrl) 

(setq  booll  (null  (car  taplt))  chi  I  ()) 
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(setf  s-ptrl  s-ptr) 

(do*  ((■  tip  It  (cdr  «)) 

(j i  (e»r  «)  (car  a))) 

((or  (null  i)  (null  y)  booll)  (or  (and  booll  (or  ckil  booll)) 

(and  (setf  s-ptr  s-ptrl)  nil))) 

(setf  s-ptr  s-ptrl) 

(aultiple-vatue-setq  (chil  booll)  (p-aatch-2  y)))) 

Option  catcher 


..  This  function  tries  to  aatch  a  parse  teaplate  against  the  current  sentence 
tokens  If  it  succeeds  it  returns  tuo  values.  The  first  is  a  list  of 
..  children  created  vhile  aatching  things  and  the  second  is  T.  If  it  fails 
..  the  first  value  is  undefined  and  the  second  value  is  til. 

(defun  p-aatch-2  (tap  laui  t-node  p-node  fbool) 

(setf  p-node  0  fbool  t) 

(do* 

((>  tap  (cdr  i)) 

(y  (car  «)  (car  «))) 

((or  (null  >)  (null  fbool))  (values  p-node  fbool)) 

(cond  ((null  y)  0) 

((a toe  y) 

(cond  ((setf  t-node  (p-aateh  y)) 

(setf  p-node  (append  p-node  (filt-t  t-node)))) 

(t  (setf  fbool  nil)))) 

((equal  (car  y)  ’•opt*) 

(setf  p-node  (append  p-node  (filt-t  (p-eatch  (cadr  y)))))) 

((equal  (car  y)  **ignore«) 

(setf  fbool  (not  (null  (p-aatch  (cadr  y)))))) 

((and  (equal  (car  y)  ’*fuac*) 

(funcall  (cadr  y)  (car  (aref  seateace  s-ptr)))) 

(setf  p-node  (append  p-node 

(list  (aake-aode  aaae  (car  (araf  sentence  s-ptr)) 

line  (cdr  (ref  sentence  s-ptr)))))) 

(incf  s-ptr)) 

((and  (equal  (car  y)  ’*par*) 

(setf  t-node  (p-aatch  (cadr  y)))) 

(aultiple-value-bmd  (q-aodes  bool)  (p-aatch-2  (cdr  a)) 

(cond  (boot 

(setf  (node-children  (car  t-aode)) 

(append  p-aode  q-aodes)) 

(setf  a  ail) 

(setf  p-aode  t-node)) 

(t  (setf  fbool  ail))))) 

((equal  (car  y)  ’*func*)  (setf  fbool  ail)) 

((equal  (ear  y)  '*a*l*) 

(or  (and  (setf  t-node  (p-aatck-aal  (cdr  y))) 

(setf  p-node  (append  p-node  t-node))) 

(setf  fbool  ail))) 

((equal  (car  y)  ’•null*) 

(or  (and  (setf  t-node  (p-aatck-aull  (cdr  y))) 

(setf  p-aode  (append  p-aode  t-node))) 

(setf  fbool  ail))) 

(t  (error  ‘PARSE:  Bad  8HF  option  *))))) 


..  Option  aatcher  Utilities 


This  function  filters  out  all  T‘s  vhich  are  introduced  by  Batches  that 
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don't  create  any  children. 

(defen  filt-t  (I)  (if  (eg  I  t)  nil  I)) 

;;  This  function  is  called  by  p-aatch-2  to  take  eare  of  the  *Bnl*  teaplate 
;;  option.  The  algoritha  used  is  eiplaieed  ia  PARSE.DAT. 

(defun  p-aatch-aul  (tap  Aaui  p  q) 

(coed  ((null  (setf  p  (p-aatch  (car  tap)}))  (values  0  ())) 

(t  (do  () 

((or  (>«  s-ptr  (length  sentence)) 

(null  (aeaber  (car  (aref  sentence  s-ptr))  (cadr  tap)))) 
(values  p  t)) 

(incf  s-ptr) 

(setf  p  (list  (aake-node  ease  (car  (aref  sentence  (1-  s-ptr))) 
children  (setf  q  (append  p  (filt-t 

(p-aatch  (car  tap))))) 
line  (edr  (aref  sentence  (1-  s-ptr)))))) 

(aape  *’ (laabda  (i)  (setf  (node-parent  i)  (car  p)))  q))))) 

;;  This  function  is  called  by  p-aatch-2  to  take  care  of  the  *antl*  teaplate 
::  option.  The  algoritha  used  is  explained  ia  PARSE.DAT. 

(defun  p-aatch-aull  (tap  fcaux  p  q) 

(coed  ((null  (setf  p  (p-aatch  (car  tap)}))  (values  ()  ())) 

(t  (do  () 

((or  (and  (cadr  tap)  (incf  s-ptr)  nil) 

(>*  s-ptr  (length  sentence)) 

(end  (cadr  tap) 

(null  (aeaber  (car  (aref  sentence  (1-  s-ptr))) 

(endr  tap)))) 

(null  (setf  q  (p-aatch  (car  tap))))) 

(progn  (and  (cadr  tap)  (deef  s-ptr))  (values  p  t))) 

(setf  p  (append  p  (filt-t  q))))))) 


Load  the  parenthesized  BNF  for  the  subset  of  PASCAL  that  is  needed. 
Vritten  by  Bret  Mallach  10/23/84 

This  file  contains  the  inforaation  necessary  to  parse  and  bsild 
a  parse-tree  for  the  subset  of  PASCAL  that  IMcro-Proust  is  esing. 

Only  one  week  was  allocated  for  progressing  the  parser.  As  a  result 
there  certainly  are  bugs  ia  ay  PASCAL  language  definitioa. 

Each  tiae  a  parse  var  coapletely  aatches,  a  parse-tree  node  is 
built  using  the  'parent  property  as  the  naae.  If  the  'parent 
property  is  nil,  then  no  new  nodes  are  created  and  the  children 
nodes  are  passed  along  instead.  See  PARSE. LSP  for  additional 
detai Is. 

The  following  options  are  allowed  for  a  aatch. 

1.  ‘ignore*  aeans  that  the  object  sust  aatch,  but  doa't  create 
a  child  node  for  it. 

2.  *opt*  aeans  try  to  aatch  the  object,  but  if  it  doesn’t  aatch, 
skip  it. 

3.  «func*  aeans  apply  the  following  laabda  expression  to  the 
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carreat  tokea  a *4  if  T  is  retareed.  consider  it  s  satck 
as  mg  tka  aait  toksa  as  tka  aaaa  of  a  aaa  ckild  aoda. 

4  spars  aaaas  tkat  tkis  itaa  aast  aatek  sad  tkaa  will  ba  asad 
as  tka  aode-aaae  of  tka  paraat  aoda  or  all  tka  rast  of  tka 
aatckad  objects 

5  ssats  is  asad  to  kaild  tka  aiprassioa  sab-traas.  Tkis  is  koa 
it  is  asad 

Stap  I  Try  to  aatek  tka  first  argaaaat.  If  it  aatchas 

rrasta  aoda  i  for  it  sad  go  to  Stap  2.  otkaraisa  qeit. 
Stap  2  Try  to  aatek  aay  of  tka  alaaaats  of  tka  second 

argaaaat  aad  tkaa  tka  first  argaaaat  agaia.  If  tkay 
aatek  create  sodas  y  aad  z  for  botk  aatekas 
raspaetiaaly  Rake  y  tka  paraat  aoda  aitk  i  as  tka 
I  aft  ckild  aad  z  as  tka  right  ckild.  Sat  a  ■  y.  Co  to 
Stap  2  Elsa  ratara  a. 

•  soeits  is  asad  to  sisplify  right  reearsiee  rales.  For  eiaaple,  the 
folio* I ag  tea  teap Iotas  for  sgs  pith  ail  paraat  propsrtias  aoald 

ha  i  id  tka  esoa  parse  sab-traa 

((•he  \.  •*•)  (»hs))  ;  •••  : :■  sh*  •••  I  sbs 

(((••alls  she  (\.))))  .  •••  : *b*  *bs> 

Tka  sacood  argaaaat  is  tka  itaa  to  ba  repeated,  aad  tka  third 
argaaaat  is  a  list  of  possible  separators. 

Rotas  for  aritiag  aaa  rales 

Do  sot  asa  aay  left  reearsiee  rales.  These  sill  boob  the  prograa. 

If  a  rale  has  a  right  reearsiee  optioa,  pat  that  optioa  first. 

Rlaays  create  the  rales  so  they  aatch  as  sect  as  possible. 

•opts  is  like  Q  ia  EBRf 
seals  is  like  {}  ia  EBRf 

•sails  is  also  like  (}  ia  EBRF  bat  pracadaaee  is  aot  coasidarad. 


;;  sprograa  : "PROGRAM*  *id  [sprog-kaadar]  [sdaels]  saaia-block  scad 
(dps  sprograa 
taaplata 

(((•igaoras  PROGRAM)  aid  (*opt*  sprog-kaadar) 

(•opts  sdaels)  saaia-block  (sigaore*  seed))) 
paraat  PROGRAM) 

saaia-block  •BEGIN1  sstataaeats  I  •BECIM* 

(dps  saaia-block 

taaplata 

(((•igaoras  BEGIN)  sstataaeats) 

((•igaoras  BEGIN))) 
paraat  BEGIN) 

;;  seed  "END;*  I  •END.* 

(dps  *ead 

taaplata 

(((♦igaoras  END)  (sigaoras  \;))  ((signoras  END.))) 
paraat  ail) 
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;;  ‘prog-header  *pli-list  •)• 

(dps  ‘prog-header 
teaplate 

(((•ignore*  \()  ‘ph-list  (‘ignore*  \))  (*ig*ora*  \;))) 
parent  PROC-HEADER) 

;;  ‘ph-list  *id  {•.*  *id} 

(dps  *pk-list 

teaplate 

(((•aall*  *id  (\. )))) 
pareat  ail) 

;;  *deels  «const-decls  *»ar-decls  I  ‘const-dec Is  I  *rar-deels 
(dps  *decls 

teaplate 

( (‘const-dec Is  *«a r-dec I s) (*eoast-dee I s) (*va r-dee I s) ) 
parent  DECIS) 

;;  *coast-decls  “CORST*  ‘const- list 

(dps  *const-decls 

teaplate 

((CORST  ‘const- list)) 
pareat  COHST-DECtS) 

;;  ‘const- list  ‘const  {‘coast) 

(dps  ‘coast- list 

teaplate 

(((‘aall*  ‘const  ()))) 
parent  nil) 

;;  ‘const  : ‘id  ‘eapr 
(dps  ‘const 

teaplate 

((•id  (‘ignore*  *)  ‘eapr  (‘ignore*  \;))) 
parent  CORST) 

;;  ‘bool-eipr  : ‘eapr  ‘bool-op  ‘eapr 
(dps  *bool-eapr 

teaplata 

((‘eapr  (‘par*  ‘bool-op)  *eapr)) 
pareat  nil) 

;;  ‘bool-op  : *bool-ne  I  ‘bool-ge  |  ‘bool-le  |  ... 

(dps  ‘boo I -op 

teaplate 

((•bool-ne) (‘bool-ge) (‘bool-le) 

(•bool-eq) (‘bool-lt) (‘bool-gt)) 
pareat  ail) 

; ;  ‘bool-eq  : :• 

(dps  ‘bool-eq 

teaplate 

(((•ignore*  \«))) 
parent  \“) 


;;  ‘bool-lt  : :■  ■<• 

(dps  ‘bool-lt 
teaplate 

(((•ignore*  \<))) 
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parent  \<) 

;;  *bool-gt  : :*  •>■ 

(dps  *bool-gt 
teaplat* 

(((•ignore*  \>))) 
parent  \>) 

;;  *bool-ne  : :*  •<>■ 

(dps  «bool-ne 

teaplat* 

(((•ignore*  \<)  (*ignore*  \>))) 
parent  \<\>) 

;;  *bool-ge  : :»  •>«• 

(dps  *bool-g* 

teaplate 

(((•ignore*  \>)  (*ignore*  \*))) 
parent  \>\*) 

;;  *bool-le  : :«  ■<■• 

(dps  *bool-l* 

teaplat* 

(((•ignore*  \<)  (*ignore«  \*))) 
parent  \<\*) 

;;  *e*pr  : *tere  «tera  I  *tera  I  "OR*  *tera) 

(dps  *expr 

teaplate 

(((•ael*  *tera  (V*  \-  OR)))) 
parent  ()) 

;;  *t*ra  *fact  {■*•  *fact  I  •/■  ‘fact  I  ■0I¥*  *fact 

I  “ROD*  *fact  I  •MID*  *fact> 

(dps  *tera 

teaplat* 

(((•as I*  ‘fact  (\*  V  DIV  ROD  MID)))) 
parent  ()) 

;;  *fact  ■(■  **ipr  •)•  I  *id-or-naa  I  •e-ainas-fact 

I  •n-plns-fact  t  •not-fset 

(dps  *fact 

teaplat* 

(((•ignore*  \()  *e*pr  (*ignore*  \))) 

(•id-or-nna) (•e-ainns-fact) (•a-pl*s-fact)(*not-faet)) 
parent  ()) 

;;  •a-ainns-fnct  : *fact 
(dps  e*-ain*s-fact 
teaplat* 

(((•ignore*  \-)  *fnct)) 
parent  \-) 

;;  •e-plas-faet  *faet 

(dps  ea-p lea-fact 
teaplate 

(((•ignore*  Y»)  *fact)) 
parent  nil) 
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::  *aot-fact  •HOT*  *fect 
(dps  *not-fect 

teaplate 

(((•ignore*  NOT)  *feet)) 
psr«*t  NOT) 

;;  *eipr-list  : *e*pr-or-string  *eipr-oi— string) 

(dps  *eipr-list 

taaplata 

(((•aull*  *expr-or-string  (  \,)))) 
psrest  si  I) 

*eipr-or-string  *eipr  [*»-foraat]  I  string 
;;  where  string  is  predefined 
(dps  *e*pr- or-string 

teaplate 

((*eipr  (*opt*  *w-foraat))  ((*fnne*  (laabda  (war)  (striagp  var))))) 
parent  nit) 

;;  •w-foraat  *int  *iat  I  *int 

(dps  *w-foraat 

teaplate 

(((♦ignore*  V)  (*ignore*  eint)  (eignore*  \:)  (* ignore*  eint)) 
((♦ignore*  V)  (*ignore*  *iat))) 
parent  nil) 

; ;  *int  is  predefined 
(dps  *int 

teaplate 

(((•func*  (laabda  (var)  (integerp  var))))) 
parent  nil) 

;;  *var-decls  "VAR*  *var-list 
(dps  *var-decls 

teaplate 

(((•ignore*  VAR)  *var- list)) 
parent  VAR-DECLS) 

;;  *var-list  *var  {*var) 

(dps  *var-list 

teaplate 

(((*aell*  *var  ()))) 
parent  nil) 

;;  *var  • id— I ist  *ver-type  ■;■ 

(dps  *var 

teaplate 

((•id-list  (*igeore*  \:)  *ver- type  (‘ignore*  \;))) 
parent  VAR) 

;;  *var-type  "REAL*  I  ■INTEGER* 

(dps  *var-type 

teaplate 

((REAL) (INTEGER)) 
parent  nil) 

;;  *begin-block  "END*  I  estateaents  •END* 

(dps  *begia-block 
teaplate 
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(((•ignore*  END)) 

(•stateaents  (* ignore*  END))) 
parent  BEGIN) 

;  *stateaents  *stateaent  *stateaent) 

(dps  *stateaents 

teaplate 

(((•aull»  *stateaent  (\;)))) 
parent  ai I) 

;  *seai  : :* 

(dps  *seai 

teaplate 

(((•ignore*  \;))) 
parent  nil) 

;;  *stateaeat  *ass-stateaent  I  'IF*  *if-stateaent  |  *begia-block  . 
(dps  *stateaent 

teaplate 

((*a$s-stateaent)  ((‘ignore*  IE)  *i f-stateaent) 

((•ignore*  BEGIN)  *begin-bloek) 

((•ignore*  WHILE)  *vhi le-stateaent) 

((•ignore*  REPEAT)  *repeat-stateaent) 

((•ignore*  WRITE).  N)  *«riteln-stateaent) 

((•ignore*  WRITE)  *write-stateaent) 

((•ignore*  READ)  *read-stateaent) 

((•ignore*  READIN)  ‘read  I n-stn tenant) 

((•ignore*  CASE)  *case-stateaent)  (*»nl l-stateaeat)) 
parent  nil) 

;;  *nn I l-stateaeat  •• 

(dps  *nnl l-stateaent 

teaplate 

(()) 

parent  nil) 

;;  *ass-statenent  *id  *e«pr 

(dps  *ass-stateaeat 

teaplate 

((♦id  ('ignore*  \:)  (• ignore*  \»)  *eipr)) 
parent  :■) 

.  *wki le-stateaent  *boot-expr  *D0*  *statcaent 
(dps  *aki le-stateaent 

teaplate 

((•bool-eipr  (‘ignore*  DO)  *stateaent)) 
parent  WHILE) 

;;  *repeat-stateaent  : :■  *repeat-list  'UNTIL*  *bool-eipr 
(dps  *repeat-stateaeat 

teaplate 

((•repeat-list  (‘ignore*  UNTIL)  *bool-e«pr)) 
parent  REPEAT) 

;;  ‘repent- list  *stateaeats 
(dps  *repeat-list 

teaplate 
((•stateaents)) 
parent  STATENENT-LIST) 
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;;  •srite-stateaent  *«rite-list 
(dps  *erite-stateaent 
teaplste 

(((•opt*  *»rite-l ist))) 
parcst  WRITE) 

;;  •ariteln-stateaent  *arit«-list 
(dps  *eritel a-stateaaat 

teaplste 

(((•opt*  •ante- 1  ist))) 
parent  WRITELH) 

;;  *«rite-list  : :■  •(■  *eipr-list  •)■ 

(dps  »»rite-list 

teaplste 

(((•ignore*  \()  »e*pr-list  (‘ignore*  \)))) 
parent  ni I) 

;;  •resd-ststeaent  *read-list 
(dps  • resd-ststeaent 

teaplste 

(((•opt*  *resd-l ist))) 
parent  READ) 

;;  *resd I n-ststeaent  : • read- I ist 
(dps  *readf n-stateaent 

teaplste 

(((•opt*  *read-l ist))) 
parent  READLN) 

;;  «read-list  ■(■  • I i st— i d  *)• 

(dps  *read-list 

teaplste 

(((•ignore*  \()  ‘list-id  (*ignore»  \)))) 
parent  nil) 

;;  *case-ststeaent  *e*pr  ■OF*  *case-list  [•;■]  'END* 

(dps  *case-stateaent 

teaplste 

((•eipr  (‘ignore*  OF) 

•case-list  (*opt*  *seai)  (‘ignore*  END))) 
parent  CASE) 

;;  ‘case-list  ‘case-part  *case-list  I  ‘case-part 
(dps  *ease-l ist 

teaplste 

((•case-pert  (‘ignore*  \;)  *case-list)  (*case-part)) 
parent  ail) 

;;  *case-part  ‘case-const  *stateaent 
(dps  *case-part 

teaplste 

((•ease-const  («ignore*  \:)  •stateaeet)) 
parent  CASE-PART) 

;;  •case-const  •case-const- I ist 

(dps  •case-const 

teaplste 
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( (•case-const- I i st) ) 
parent  CONST-LIST) 

*case-const-l ist  : :=  •id-or-naa  •ease-const- I ist  I  •  id-or-nan 
(dps  *case-const-l ist 

teaptate 

((•id-or-naa  (*ignore*  \.)  *case-const-l ist)  (•id-or-noa)) 
parent  nil) 

;;  *id-or-nea  »id  I  »n«a 
(dps  *id-or-n«a 

teaplate 
((•id)  (*naa)) 
parent  nil) 

;;  *if-stateaent  •bool-eapr  "THEN*  *stateaent  [*else-p] 

(dps  • i f-stateaent 
teaplate 

((•bool-eapr  (*ignore*  THEN)  *stateaent  (*opt*  *e I se— p) ) ) 
parent  IF) 

.  *else-p  : :•  ‘ELSE*  *stateaent 
(dps  «elsc-p 

teaplate 

(((•ignore*  ELSE)  *stateaent)) 
parent  nil) 

;  • id— I ist  : :•  *1 i st— i d 
(dps  *id-list 

teaplate 
((•1 ist-id)) 
parent  id- I ist) 

;;  *1 ist-id  • :«  »id  {*.■  *id) 

(dps  *1 ist-id 

teaplate 

(((•Ball*  *id  (  \.)))) 
parent  ail) 

;  »id  is  predefined 
(dps  *id 

teaplate 

(((•fane*  (laabda  (i) 

(sad  (>•  (ckar-epcase  (aref  (string  i)  0))  t\A) 

(<■  (ckar-apcase  (aref  (string  a)  0))  #\Z)))))) 

parent  nil) 

»nae  is  predefined 
(dps  *naa 

teaplate 

(((•fane*  (laabda  (a)  (naaberp  a))))) 
parent  a • I ) 


..  Load  tbe  Eaplain  aisaateked  gronp 

..  Contains  tke  fol  loamg  reactions  and  tknir  sapportiag  fanetions: 
Eaplain-aisaatckes.  eval-aalforaed-rales.  single-eaal-aalforaed. 
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i tea-eva l-ea I foraed .  eval-s-eslforaed-rale.  eval-aissing-rales.  *nd 
single-eval-aissing. 

Explain  Mismatches  fenctioas  EXPLAIN. ISP 

Written  by  Bret  Vallach  10/23/84 


Explain  a i snatches 


;;  This  feactioa  calls  eva I -aa I foraed-rales  and  then  eval-aissing-rales 
;;  to  try  to  explain  aisastches  in  the  plans.  If  one  of  those  tao  fanctions 
;;  returns  a  plan  (aeaning  that  all  aisaatches  for  the  plan  are  explaiaed). 

;;  the  plan  is  set  to  enblocked.  and  the  component  address  is  increased  by  1. 
(defun  explaia-aisaatches  (plans) 

(let  ((nea-plan 

(or  (eval-aalforaed-rales  plans) 

(eval-aissing-rales  plans)))) 

(cond  (nea-plan 

(setf  (ins-statns  nea-plan)  ()) 

(incf  (ins-address  nea-plaa)) 
nea-plan) 

(t  ())))) 


Use  the  aalforaed  rales  to  explain  aisaatches  in  tha  plans 


;;  Eual-aal foraed-rales  call/  Single-Eva  I -Hal foraed  for  each  plan. 

(dcfan  eval-aal foraed-rales  (plans) 

(coed 

(plans  (or  (singlc-eval-aalforaed  (car  plans)) 

(eval-aalforacd-rales  (cdr  plans)))) 

(t  ()))) 

;;  This  faactioa  gets  each  aatch-fraae  froa  the  partiats  slot  of  the  plan 
..  instantiation  and  passes  it  to  itea-evs I -aalforaed  so  that  the  errors 
,,  caa  be  explained.  If  the  errors  are  expleiaed  the  plea  is  returned, 
(defan  single-eval-aalforaed  (plan) 

(let  ((partial  (pop  (ies-partials  plan)))) 

(cond  (partial 

(foraat  t  •"!  Partial:  "a*  (aatch-fraae-errors  partial)) 
(foraat  t  *~f  Plan-aaae:  "a*  (ias-aaaa  plea)) 

(or  (aad  (i tea-aval -aalforaed  plan  partial) 

(setf  (aref  (ias-satches  plan) 

(ins-address  plan)) 

(list  (astch-fraae-code  partial))) 

plea) 

(siagle-eval-aatforaed  plan))) 

(t  ())))) 

..  This  fanctioa  applies  each  aalforaed  rale  to  a  aatch-fraae  anti  I 
..  the  errors  are  expleiaed  or  there  ere  no  rales  left. 

(dcfan  itee-eval-eslforsed  (plsa  aatch-fraae) 

(do*  ((i  can  I foraed-rales*  (cdr  x)) 

(y  (car  x)  (car  i))) 

((or  (nail  x)  (eval-a-ealforaed-rale  plaa  aatch-fraae  y)) 

(coed  (x 

(aad  axec-oat 

(foraat  t  •fNatch  error  explained  by  'a  ia  plsa  'a.* 
y  (ias-aaae  plan))) 

pies) 
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(t  ()))))) 

. .  This  function  ashes  sere  that  each  part  of  a  aalforaed  rale  is  satisfied. 
;;  The  bag  rale  actios  is  perforaed  if  this  is  the  case. 

(defua  e»a l-a-ea I foraed-ra le  (plaa  aatch-fraae  rule) 

(let  ((eiplaiaed-errors  0)) 

(aad  (plaa-coapoaeat  plaa  rale) 

(expected  aatch-fraae  rale) 

(plan-test  plaa  rale) 

(test-code) 

(>*  explained-errors  (length  (aatch-f raae-errors  aatch-fraae))) 
(actios)))) 

■;  Use  the  aissiag  rules  to  eiplaia  aisaatchas  ia  the  plans 


. .  Eval-aissing-rules  calls  Single-Easl-Missing  for  each  plaa. 

(defua  eval-aissing-rules  (plans) 

(coad 

(plans  (or  (single-eval-aissing  (car  plans)) 

(eval-aissing-rules  (cdr  plans)))) 

(t  ()))) 

;  This  function  applies  each  aissiag  rale  to  the  plan-instantiation  until 
the  errors  are  eiplained  or  there  are  no  rules  left.  If  one  of  the 
;;  rules  fires,  the  plan-coapoaeat  is  said  to  Batch  the  sane  thing  as  the 
first  plan  coaponeat. 

(defun  single-eval-aissing  (plaa) 

(do*  ((«  *a i ss i ng— re  I es«  (cdr  i)) 

(y  (car  a)  (ear  u))) 

((or  (null  u)  (eval-a-aissing-rule  plan  jf)) 

(cond  («  (setf  (aref  (ins-aatches  plaa) 

(ins-address  plan)) 

(aref  (ins-aatches  plan)  0)) 

(and  eiec-out 

(foraat  t  "Hutch  error  explained  by  "a  ia  plaa  "a." 
y  (ins-naae  plan))) 
plan)  (t  ()))))) 

. ;  This  function  ashes  sure  that  each  part  of  a  aissiag  rule  is  satisfied. 

;;  The  bug  rule  action  is  perforaed  if  this  is  the  case. 

(defun  eval-a-aissing-rule  (plan  rule) 

(and  (plan-coaponent  plan  rule) 

(plan-test  plan  rule) 

(test-code) 

(action))) 


Explain  Uti I ities 


This  function  aakes  sure  that  the  coaponeat  that  didn’t  aatch  is  refered 
. ,  to  by  a  label  stateaent  ia  a  later  plan  coaponeat.  If  there  is  no 
'plan-coaponent  property  (this  is  the  label),  then  return  T. 

(defun  plaa-coaponent  (plan  rule) 

(let  ((eur-addr  (♦  (ins-address  plan)  1)) 

(ten  (length  (ins-aatches  plan))) 

(taplt  (get  (ins-naae  plan)  ‘teaplste)) 

(label  (get  rule  ’plan-coapoaeat))) 

(cond  ((null  label)  t) 

(t  (do  ((i  cur-eddr  (♦  i  1))) 
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((or  (equal  i  lea) 

(and  (equal  (car  (aref  taplt  i))  ’label) 

(equal  (cadr  (aref  taplt  i))  label) 

(equal  (cadar  (caddr  (aref  taplt  i))) 
cur-addr))) 

(not  (equal  i  Ian)))))))) 

;;  This  function  analyzes  the  'eipected  and  ’found  properties  of  the 
;;  bug  rule.  If  both  properties  eaist,  then  a  cons  of  the  fora 
. .  (eipected  .  found)  is  sought  in  the  aatch-fraae  errors. 

;;  If  there  is  no  'expected  property,  but  there  is  a  ’found  property. 

;  then  there  aust  be  a  cons  of  the  fora  (i  .  found)  ahera  x  can 
;;  be  anything.  If  neither  property  exists  then  true  is  returned. 

(defun  expected  (aatch-fraae  rule) 

(let  ((exptd  (get  rule  ‘expected)) 

(fnd  (get  rule  ’found))) 

(cond  ((and  (null  exptd)  (null  fnd))  t) 

((and  (null  exptd) 

(not  (null  (rassoc  fnd  (aatch-fraae-errors 

aatch-fraae))))) 

(incf  explained-errors)  t) 

(t  (let  ((arg  (cdr  (assoc  exptd  (aatch-fraae-errors 

aatch-fraae))))) 

(cond  ((or  (equal  fnd  arg)  (aeaber  fnd  arg)) 

(incf  explained-errors)  t) 

(t  ()))))))) 

;;  This  function  aahes  sure  the  plan  errors  being  explained  are  part  of 
;;  a  specified  plan.  If  there  is  no  'plan  property,  return  T. 

(defun  plan-test  (plan  rule) 

(let  ((plnn-naae  (get  rule  ’plan))) 

(or  (null  plan-naae)  (equal  plan-naae  (ins-naae  plan))))) 

;;  This  function  executes  the  test  pnrt  of  the  rule  and  returns  its  result. 
;;  It  returns  T  if  there  is  no  test  function  associated  with  the  rule, 
(defun  test-code  () 

(let  ((func  (get  rule  ’test-code))) 

(or  (null  func)  (funcall  func)))) 

;;  This  function  fires  the  action  part  of  the  rule  and  returns  T. 

(defun  uction  () 

(setf  «bug-report*  (append  ubug-report» 

(list  (funcall  (get  rule  ’action)))))  t) 


Bug  rules  8UCS.LSP 

Written  by  Bret  Wallach  10/23/84 

This  file  contains  the  test  action  pairs  and  the  report  functions 
for  the  bug  rules. 

The  variable  explained-errors  contains  the  naaber  of  aisaatches  that 
have  been  explained  by  the  bug  rules.  All  aisaatches  have  to  be 
explained  before  the  action  part  of  a  rule  will  fire. 

Uti I ities 


Returns  the  node  in  the  *parse-tree*  that  the  bug  is  associated 
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(defun  bug-stateaent  (bag) 

(natch-f reae-code  (cdr  (assoc  ’statement  bag)))) 

;; Returns  the  cosponent  label  of  the  bug 
(defun  bug-eoaponent  (bug) 

(cdr  (assoc  ‘coaponent  bug))) 

;;Returns  the  goal  label  of  the  bug 
(defun  bug-goal  (bug) 

(cdr  (assoc  'goal  bug))) 


.  .Whi le-for-if  rule 


(defun  uh i le-for-i f-aetion  () 

• (uhl le-for-if  (stateaent  .  .aatch-f raae))) 

(dps  «hi le-for-if  expected  if  found  uhile  action  uhi le-for-i f-act ion 
report-fun  report-uh i le-for-i f) 

(defun  report-vhi le-for-if  (bug) 

(foraat  t 

■You  used  a  WHILE  stateaent  at  line  *a  (there  you  should  have  used  an  IF.* 
(node-line  (bug-stateaent  bug)))) 

; .Read-is-counter  rule 


(defun  check-read- is-eounter  () 

(let  ((var  (node-naae  (car  (node-children  (aatch-f raae-code  aatch-f raae))))) 
(incr  (cadr  (assoc  ()  (aatch-f raae-errors  aatch-f raae))))) 

(and  (equal  (length  (aatch-fraae-errors  aatch-fraae))  2) 

(equal  (car  incr)  '♦) 

(equal  (cadr  incr)  var) 

(equal  (caddr  incr)  *1) 

(incf  explained-errors) 

(incf  explained-errors) 
t))) 

(defun  read- is-counter-act ion  () 

'(read-is-counter  (stateaent  .aatch-f reae))) 

(dps  read-is-counter  expected  read  found  :* 

test-code  check-read- is-counter  action  reed- is-counter-act ion 
report-fun  report-read- is-counter) 

(defun  report-read-is-counter  (bug) 

(foraat  t 

■It  appears  that  you  uere  trying  to  use  line  *•  to  read  the  next  input 
value.  Increaenting  *a  vill  not  cause  the  next  value  to  be  read  in.  Yon 
need  to  use  a  reed  stateaent  here . * 

(node-line  (bug-stateaent  bug)) 

(node-naae  (car  (node-children  (bug-stateaent  beg)))))) 


.  .Sun  is  counter  rule 


(defun  sua-is-counter-aetion  () 

' (sua-is-eounter  (stateaent  .  .aatch-fraae))) 
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H.2  EXAMPLE2.PAS 


PROGRAM  Averige2(  INPUT ,  OUTPUT  ); 

VAR  SUN,  COUNT.  NEM:  INTEGER; 

AVC  REAL. 

BEGIN 
SUN  :■  0; 

COUNT  =0; 

NEM  =0. 

MHILE  NEM<>9999  DO 
BECIN 

READ(  NEM  ); 

SUN  *  SUNKEN; 

COUNT  :=C0UNT*1; 

END. 

IF  C0UNT=0  THEN 
MRITELN(  ’NO  DATA  ENTERED1  ) 

ELSE 

BECIN 

AVC  -SUN/COUNT; 

MRITELN(  ‘THE  AVERAGE  IS  \  AVC  ) ; 
END 


END. 


Micro-PROUST  Code 


II.  Sample  Pascal  Programs 


H.1  EXAMP  LEl.PAS 


PROCRAB  Average  ( inpat. oatpat) ; 
VAR  Saa.  Coot,  Nea:  INTEGER; 

Avg:  REAL; 

BEGIN 
Saa  :■  0; 

Coont  :■  0; 

Read  (Nea); 

WHILE  Nea<>9999  DO 
BECIN 

Saa  :■  Sua+Nea; 

Coont  :»  Coant*l; 

Neo  :»  New  ♦  1 

END; 

Avg  :*  Soa/Count; 

WRITELN  ('The  average  is  ’.avg); 
END; 
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(OTHERWISE  (APPLY  #‘DRIBBLE-IH  ARCS)))) 


Miero-PROUST  Code 


1.8  DREBBLE.LSP 

;;;  tttdribble. Isp 

;;;  Copyright  (c)  Cold  Hill  Coaputers,  Inc  1984 

;;;  The  DRIBBLE  facility  (slurp) 

The  on  I y  topleuel  function  in  this  file  is  DRIBBLE. 

(DEFVAR  eDRIBBLE-STREAN#  NIL)  ;  the  DRIBBLE  output  stress 

(DEEVAR  eDRIBBLE-TERRINAL*  MIL)  ;  during  DRIBBLE  this  is  teraiasl 

(DEFUN  DRIBBLE  (BOPTIONAL  PN) 

■DRIBBLE  uith  a  psthnaae  arguaent  start  the  dribble  operation,  aith 
no  psthnaae  arguaent  ends  the  dribble  operation.* 

(COND  ((AND  PN  (NULL  eDRIBBLE-STREARe))  ;  open  dribble  file 

(SETQ  eDRIBBLE-STREAN*  (OPEN  PN  : DIRECTION  :0UTPUT) 

•DRIBBLE-UMTTI*  NIL 
•DRIBBLE-TERHINAL*  eTERNINAL-IO* 

•TERNINAL-IO*  f’DRIB8LE-TERN) 

T) 

((AND  (NULL  PN)  eDRIBBLE-STREAN*)  ;  close  dribble  file 

(SETQ  eTERNINAL-IO*  eDRIBBLE-TERRINAL*) 

(CLOSE  eDRIBBLE-STREAN*) 

(SETQ  eDRIBBLE-STREAN*  NIL)) 

((AND  (NULL  PN)  (NULL  eDRIBBLE-STREAN*) )  ;  asked  to  close  bat  not  open 

(FORNAT  T  ■‘BDRIBBLE  not  in  progress.*)) 

((AND  PN  eDRIBBLE-STREAN*)  ;  asked  to  opes  bat  slrendy  open 

(FORNAT  T  ■'BDRIBBLE  is  alrendy  in  progress.*)) 

)) 

(DEFVAR  *DRIB8LE-UNTYI*  NIL) 

This  is  the  input  streaa  handler  during  a  dribble. 

(DEFUN  DRIBBLE-IN  (NSC  BREST  ARCS) 

(CASE  NSC 
( :  TYI 

(COND  (*DRIBBLE-UNTYI* 

(PROC1  eDRIBBLE-UNTYI* 

(SETQ  eDRIBBLE-UNTYI*  NIL))) 

(T 

(LET  ((CHAR  (SEND  eDRIBBLE-TERRINAL*  :TYI))) 

(SEND  eDRIBBLE-STREAN*  :TY0  CHAR) 

CHAR)))) 

(  UNTYI  (SETQ  eDRIBBLE-UNTYI*  (CAR  ARCS))) 

,,  foraard  to  the  real  streaa. 

(OTHERWISE 

(APPLY  *DRIB8LE-TERNINAL*  NSC  ARCS)))) 

;;  This  is  the  oatpat  streaa  handler  during  a  dribble. 

(DEFUN  DRIBBLE-OUT  (BREST  ARCS) 

(APPLY  eDRIBBLE-STREAN*  ARCS) 

(APPLY  eDRIBBLE-TERRINAL*  ARCS)) 

;;  This  is  the  streaa  for  *TERNINAL-IO*  during  e  dribble. 

;;  Depending  on  the  aessage  ae  decide  to  dispatch  to  the  input 
;  or  output  dribble  stresas. 

(DEFUN  0R1BBLE-TERN  (BREST  ARCS) 

(CASE  (CAR  ARCS) 

((:TYO  STRINC-OUT  LINE-OUT)  (APPLY  d’ORIBBLE-OUT  ARCS)) 
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(♦  OFFSET  INITIAL -OFFSET) 
NAHEDP 

PRINT-FUNCTION 

CONSER 

PREDICATE 

))) 


offset  to  stractare  eleaeats 
Bketer  its  naaed 
the  prist  fasetios  or  NIL 
asaa  of  tks  eosssr  or  NIL 
ass*  of  prsdicsts  or  NIL 


;  Th«  stractara  definition  info  is  kept  on  tke  STRUCTURE-DESCRIPTOR  property 
.  of  the  stractare  naae.  It  consists  of  a  list: 

;  (  slot-el ist  type  options) 

(DEFNACRO  DEFSTRUCT  FRN 

(LET*  ((SLOTS  (NAPCAR  ’ (LANBDA  (X)  (IF  (CONSP  X)  X  (NCONS  X)))  (CDR  FRN))) 
(S-NAHE  (IFN  (CONSP  (CAR  FRN))  (CAR  FRN)  (CAAR  FRN))) 

(OPTIONS  (IF  (CONSP  (CAR  FRN))  (CDAR  FRN)  NIL)) 

(RESULT  ' ( ' . S-NANE) ) 

(SLOT-ALIST)) 

(IF  (STRINCP  (CAAR  SLOTS))  (POP  SLOTS))  ;  daap  DOC  string 

(NULTIPLE-VALUE-BIND  (CONC-NANE  STRUCT-TYPE  OFFSET  NAREDP 
PRINT-FUNCTION  CONSER  PREDICATE) 
(DEFSTRUCT-PROCESS-OPTIONS  S-NANE  OPTIONS) 

(SETQ  SLOT-ALIST  ;  entries:  (SLOT-NANE  INDEX  DEFAULT) 

(DO  ((I  OFFSET  (!♦  I)) 

(SLOT  SLOTS  (CDR  SLOT)) 

(ALIST  NIL  (CONS  (IF  (CONSP  (CDAR  SLOT)) 

(LIST  (CAAR  SLOT)  I  (CADAR  SLOT)) 

(LIST  (CAAR  SLOT)  D)  ALIST))) 

((NULL  SLOT)  (NRE VERSE  ALIST)))) 

(PUTPROP  S-NANE 

(LIST  SLOT-ALIST 
STRUCT-TYPE 
OPTIONS 

(♦  OFFSET  (LENGTH  SLOT-ALIST)) 

NAHEDP) 

• STRUCTURE-DESCRIPTOR) 

;;  hook  into  to  tke  type  aeckasisa 
(WEN  NAHEDP  (SETF  (GET  S-NANE  ’SUPER-TYPES) 

(CONS  S-NANE  (GET  ’STRUCTURE  ’SUPER-TYPES)))) 

(DOLIST  (SLT  SLOT-ALIST)  ;  define  accessors 

(PUSH  (DEF-ACCESSOR  SLT  CONC-NANE  STRUCT-TYPE)  RESULT)) 

(WEN  CONSER  ;  define  sake  aacri 

(PUSH  (HAKE-STRUCTURE  S-NANE  CONSER  NAHEDP)  RESULT)) 

(WEN  PREDICATE  (PUSH  PREDICATE  RESULT)) 

(WEN  PRINT-FUNCTION  (PUSH  PRINT-FUNCTION  RESULT)) 

(CONS  ’PROCN  RESULT) 

))) 


;  alist  of  slots 
;  type  of  stractare 
;  options 

;  size  of  stractare 


•  ;v,-  •. 
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(DEFUN  DEFSTRUCT-PROCESS-OPTIONS  (STRUCT-NANE  OPTIONS) 

(LET  ((CONC-NANE  (STRING-APPEND  STRUCT-NANE  *\-))  ;  set  ep  defee  Its 

(TYPE  ’VECTOR) 

(OFFSET  1) 

(INITIAL-OFFSET  0) 

(EXP-NANEDP)  ;  whether  NANED/UNNANED  specified 

(NANEDP  T) 

(PRINT-FUNCTION) 

(CONSER  (INTERN  (STRING-APPEND  aNAKE-a  STRUCT-NANE))) 

(PREDICATE  T) 

) 

(DOLIST  (OPT  OPTIONS) 

(CASE  (IF  (CONSP  OPT)  (CAR  OPT)  ’ATONIC) 

(: CONC-NANE 

(SETQ  CONC-NANE  (CADR  OPT))) 

(:TYPE 

(UNLESS  (NENBER  (SETQ  TYPE  (CADR  OPT)) 

'(VECTOR  LIST  ARRAY-LEADER)) 

(ERROR  *11  lege  I  DEFSTRUCT  type:  *Sa  OPT)) 

(UNLESS  EXP-NANEDP  (SETQ  NANEDP  NIL)) 

(SETQ  OFFSET  (UPDATE-OFFSET  TYPE  NANEDP)) 

) 

(:NANED 

(SETQ  NANEDP  T  EXP-NANEDP  T  OFFSET  (UPDATE-OFFSET  TYPE  NANEDP))) 
(: CONSTRUCTOR 
(SETQ  CONSER  (CADR  OPT))) 

(■PREDICATE 

(SETQ  PREDICATE  (CADR  OPT))) 

(PRINT-FUNCTION 

(SETQ  PRINT-FUNCTION  ’ (PUTPROP  ’.STRUCT-NANE 

. (CADR  OPT) 

•PRINT-FUNCTION))) 

(: INITIAL-OFFSET  (SETQ  INITIAL-OFFSET  (CADR  OPT))) 

(ATONIC 
(CASE  OPT 

((CONSTRUCTOR  : CONC-NANE))  ;  jest  ignore 

( : NAHED 

(SETQ  NANEDP  T  EXP-NANEDP  T 

OFFSET  (UPDATE-OFFSET  TYPE  NANEDP))) 

(OTHERWISE 

(ERROR  aI I  lege  I  DEFSTRUCT  option:  ‘Sa  OPT)))) 

(OTHERWISE 

(ERROR  aII lege  I  DEFSTRUCT  option:  "Sa  OPT)))) 

(WHEN  PREDICATE 
(IF  (EQ  PREDICATE  T) 

(SETQ  PREDICATE  (IF  NANEDP 

(INTERN  (STRING-APPEND  STRUCT-NANE  a-Pa)) 
NIL)} 

(UNLESS  NANEDP 

(ERROR  aCee't  keee  PREDICATE  eith  UNNARED  etrectere")))) 

(WHEN  PREDICATE 
(SETQ  PREDICATE 
‘(DEFUN  .PREDICATE  (X) 

.(IF  (EQ  TYPE  ’LIST) 

* (EQ  (CAR  X)  ’.STRUCT-NANE) 

’(TYPEP  X  ’.STRUCT-NANE))))) 

(VALUES  CONC-NANE  ;  prefin  for  eccessor  etc roe  or  NIL 

TYPE  ;  etrectere  type 
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(TYPE  (CADR  (CET  STRUCT  ’STRUCTURE-DESCRIPTOR))) 

(STRUCTURE-DESCRIPTOR  (CET  STRUCT  'STRUCTURE-DESCRIPTOR)) 

(OPTIONS  (DEFST-OPTIONS  (CET  STRUCT  ’STRUCTURE-OESCRIPTOR))) 

(ST)) 

’(DEFRACRO  .RARE  X 
.(CASE  TYPE 
(LIST 
' ’ (LIST 

.DO  ((S  (DEFST-SLOTS  (CET  ’.STRUCT  ’STRUCTURE-DESCRIPTOR)) 

(CDR  S)) 

TERP 

(RES  . (WHEN  (DEFST-NAREDP  STRUCTURE-DESCRIPTOR) 

‘  (NCORS  ”. STRUCT)) 

(IF  (SETQ  TERP 

(OR  (CETF  X  (SLOT-RARE  (CAR  S))) 

(CAR  (SLOT-DEFAULT  (CAR  S))))) 

(CONS  TERP  RES) 

(CONS  NIL  RES)))) 

((NULL  S) (NRE VERSE  RES))))) 

((VECTOR  ARRAY-LEADER) 

"(LET  ((.’.(SETQ  ST  (RAKE-SYRBOL  «VAR*)) 

(RAKE-ARRAY  ..(OR  (CADR  (ASSOC  ’LENCTH  OPTIONS)) 

(PROC1 

(DEFST-SLOT-CNT  STRUCTURE-DESCRIPTOR) 
(WHEN  (EQ  TYPE  ’ARRAY-LEADER) 

(ERROR 

aNo  lengtk  for  array  leader*)))) 

. . (WHEN  NAREDP 

* ( : R ARED-STRUCTURE-S YRBOL  ' . STRUCT) ) 

. . (WHEN  (EQ  TYPE  ’ARRAY-LEADER) 

’ (: LEADER-LENGTH  .(LENGTH  SLOT-ALIST))) 

. . (WHEN  (OR  (RERBER  ‘HARED  OPTIONS) 

(ASSOC  ’HARED  OPTIONS)) 

* ( : NARED-STRUCTURE-SYRBOL  ’ . STRUCT) ) 
..(CDR  (ASSOC  ’RAKE-ARRAY  OPTIONS))))) 

.DO  ((S  (DEFST-SLOTS  (CET  ’.STRUCT  ’STRUCTURE-DESCRIPTOR)) 

(CDR  S)) 

TERP 

(OBJ  (NCONS  NIL)) 

(RES  NIL 
(PROCN 

(SETQ  TERP  (CETF  X  (SLOT-NARE  (CAR  S))  OBJ)) 
(WEN  (AND  (EQ  TERP  OBJ)  (SLOT-DEFAULT  (CAR  S))) 
(SETQ  TERP  (CAR  (SLOT-DEFAULT  (CAR  S))))) 

(IF  (EQ  TERP  OBJ) 

RES 

(CONS  (LIST  ’.(IF  (EQ  TYPE  ’VECTOR) 

•ASET  ’STORE- ARRAY-LEADER) 
TERP  ’.ST  (SLOT-POS  (CAR  S))) 
RES))))) 

((NULL  S) (NRE VERSE  (CONS  ’.ST  RES)))))) 

)))) 

(DEFUN  UPDATE-OFFSET  (TYPE  NAREDP) 

(COND  ((AND  (EQ  TYPE  ’ARRAY-LEADER)  NAREDP)  2) 

((OR  (AND  NAREDP  (NEQ  TYPE  ’ARRAY-LEADER)) 

(AND  (EQ  TYPE  ’ARRAY-LEADER)  (NOT  NAREDP))) 

1) 

(T  0))) 
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1.5  DEFSTRUC.LSP 

;;;  TTTdefstryc. tsp 

;;;  Copyright  (c)  Cold  Hill  Computers.  I«c.  1984 
;;  The  DEFSTRUCT  package 

;;  Motes:  The  DEFSTRUCT  package  is  aot  coapletely  COM RON  Lisp  cospstible  yet. 
::  The  accessor  sad  contractors  are  aot  faactioas  as  per  CONDOM  Lisp  bat  are 
;;  aacros,  this  Mill  be  filed.  The  slot  asses  ia  the  stractare  coastraetor 
;;  are  aot  keyaords  bat  jast  syabols  Thas  for  the  stractare: 

(DEFSTRUCT  TURTLE  HEADING  X-POS  T-POS) 

;;  the  sake  function  aoald  be: 

(NAKE-TURTLE  HEADING  90  X-POS  100  Y-POS  200). 

CORDON  Lisp  aoald  have  the  slotaaaes  be  keyaords,  eg.  :HEADINC.  This  aid 
;.  be  filed  ia  the  aeit  release. 

;;  The  carreatly  supported  options  are  shoaa  beloa: 

; ;  (DEFSTRUC  NANE-0R-0PTI0NS  1REST  SLOTS) 

Options: 

:C0NC-NAHE 

;;  CONSTRUCTOR 

INITIAL-OFFSET 
: NAMED 
: PREDICATE 
: PRINT-FUNCTION 
;;  :TYPE  {VECTOR  I  LIST) 

;;  Accessor  aacros 

;;  These  aacros  take  the  object  that  is  oa  the  STRUCTURE-DESCRIPTOR 
;;  property  of  the  stractare  naae. 

(DEFNACRO  DEFST-SLOTS  X  ‘(CAR  .(CAR  X)))  ;  retaras  st recta res  slots 

:  hard  aired  is  DESCRIBE 

(DEFNACRO  DEFST-TYPE  X  • (CADR  .(CAR  X)))  ;  retaras  type 

(DEFNACRO  DEFST-OPTIONS  X  ‘ (CADDR  .(CAR  X)))  ;  retaras  all  defstrect  optioas 

;  bard  aired  ia  DESCRIBE 

(DEFNACRO  DEFST-SLOT-CNT  X  ‘(NTH  3  .(CAR  X)))  ;  aaaber  of  slots  (local*) 
(DEFNACRO  DEFST-NANEDP  X  ‘(NTH  4  .(CAR  X))}  ;  ahathar  aaaed  stractare 

;;  These  aacros  take  a  slot  descriptor,  aeaber  of  the  DEFST-SLOTS  list. 
(DEFNACRO  SLOT-NANE  X  ‘(CAR  .(CAR  X)))  ;  naae  of  slot 

;  hard  aired  ia  DESCRIBE 

(DEFNACRO  SLOT-POS  X  ‘(CADR  .(CAR  X)))  ;  stractare  position  (local*) 

(DEFNACRO  SLOT-DEFAULT  X  ' (CDDR  .(CAR  X)))  .  defaalt  fora,  retaras  a  LIST 

(DEFUN  DEF-ACCESSOR  (SLOT-D  CONC-NANE  TYPE) 

‘(DEFNACRO  .(IF  CONC-NANE 

(INTERN  (STRING-APPEND  CONC-NANE  (CAR  SLOT-D))) 

(CAR  SLOT-D)) 

X 

.(CASE  TYPE 

(VECTOR  ‘(LIST  ‘AREF  (CAR  X)  .(CADR  SLOT-D))) 

(ARRAY-LEADER  ‘(LIST  ‘ARRAY-LEADER  (CAR  X)  .(CADR  SLOT-D))) 

(LIST  ‘(LIST  ‘NTH  .(CADR  SLOT-O)  (CAR  X)))))) 

;;  Retaras  the  aacro  that  ail  I  aaka  the  stractare. 

(DEFUN  NAKE-STRUCTURE  (STRUCT  NANE  NANEDP) 

(LET  ((SLOT-ALIST  (CAR  (GET  STRUCT  ‘STRUCTURE-DESCRIPTOR))) 
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(COND  ((>  STATE  0)  (ERROR  *B»d  pittert  to  DEFRACRO:  *S*  EPAT)) 

(T  (DEFNACRO-PARSE-A  (COR  PATTERN)  PATH  1  EPAT)))) 

((MEMBER  (CAR  PATTERN)  '(AREST  A BODY)) 

(AND  (EQ  (CAR  PATTERN)  'ABODY) 

(SETQ  *DEFNACRO-ABODY-FLAC»  T)) 

(AND  (NULL  (COR  PATTERN)) 

(ERROR  ‘Bad  patter*  to  DEFNACRO:  *S*  EPAT)) 

(COND  ((>  STATE  1)  (ERROR  'Bad  patter*  to  DEFNACRO:  *S*  EPAT)) 

(T  (DEFNACRO-PARSE-A  (CDR  PATTERN)  PATH  2  EPAT)))) 

((EQ  (CAR  PATTERN)  ‘AAUX) 

(COND  ((>  STATE  2)  (ERROR  "Bad  patter*  to  DEFNACRO:  *S*  EPAT)) 

(T  (DEFNACRO-PARSE-A  (CDR  PATTERN)  PATH  3  EPAT)))) 

((*  STATE  0) 

(DEFNACRO-COLLECT  (CAR  PATTERN)  (LIST  ’CAR  PATH)) 

(LET  ((PAIR  (DEFNACRO-PARSE-A 

(CDR  PATTERN)  (LIST  *CDR  PATH)  0  EPAT))) 

(WHEN  (CDR  PAIR)  (INCF  (CDR  PAIR))) 

(INCF  (CAR  PAIR)) 

PAIR)) 

((*  STATE  1) 

(COND  ((ATOM  (CAR  PATTERN)) 

(DEFNACRO-COLLECT  (CAR  PATTERN) 

'(CAR  .PATH))) 

(T 

(AND  (CAR  (CDDAR  PATTERN)) 

(PUSH  (CAR  (CDDAR  PATTERN)) 

•OPTION AL-SPECIFIED-FLACS*)) 

(DEFNACRO-COLLECT  (CAAR  PATTERN) 

‘(COND  (.PATH 

.(AND  (CAR  (CDDAR  PATTERN)) 

'(SETQ  .(CAR  (CDDAR  PATTERN))  T)) 
(CAR  .PATH)) 

(T  .(CADAR  PATTERN)))))) 

(LET  ((PAIR  (DEFNACRO-PARSE-A 

(CDR  PATTERN)  (LIST  'CDR  PATH)  1  EPAT))) 

(IF  (NULL  (CDR  PAIR)) 

PAIR 

(INCF  (CDR  PAIR))) 

PAIR)) 

((*  STATE  2) 

(DEFNACRO-COLLECT  (CAR  PATTERN)  PATH) 

(NHEN  (CDR  PATTERN) 

(WHEN  (OR  (ATOM  (COR  PATTERN)) 

(NOT  (EQ  (CADR  PATTERN)  'AAUX))) 

(ERROR  ■Bad  patter*  to  DEFNACRO:  *S»  EPAT)) 

(DEFNACRO-PARSE-A  (CDDR  PATTERN)  PATH  3  EPAT)) 

(NCONS  0)) 

((■  STATE  3) 

(IF  (ATOM  (CAR  PATTERN)) 

(DEFNACRO-COLLECT  (CAR  PATTERN)  NIL) 

(DEFNACRO-COLLECT  (CAAR  PATTERN)  (CADAR  PATTERN))) 

(DEFNACRO-PARSE-A  (COR  PATTERN)  (LIST  'CDR  PATH)  3  EPAT)) 

)) 

(DEFUN  DEFNACRO-COLLECT  (PATTERN  PATH) 

(COND  ((NULL  PATTERN)) 

((ATOM  PATTERN) 

;;  •••  test  of  A  keyaord  here 

(SETQ  *VARLIST*  (CONS  PATTERN  •VARLIST*)) 
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1.4  DEFMAC.LSP 

YtYdefaac.  Isp 

Copyright  (e)  Cold  Hill  Computers,  Inc.  1984 
;;  NOTE:  The  kVHOLE  optioa  is  sot  yet  sspported. 
(NACRO  DEFNACRO  (X)  (DEFRACR01  (CDR  X))) 

(DEFVAR  *OPTIONAL-SPECIFIED-FLACS*) 


::  uhether  ABODY  mss  specified 
(DEFVAR  *DEFNACR0-A80DY-FLAG*) 

;;  X  is  the  edr  of  the  DEFNACRO  fora. 

(DEFUN  DEFHACR01  (X) 

(LET  (•VARLIST*  •VALLIST*  *OPTIONAL-SPECIFIED-FLACS*  •DEFNACRO-MODY-FIAC*) 
(LET  ((PAIR  (DEFNACRO-PARSE-A 

(CADR  X)  ‘(COR  eNACROARC*)  0  (CADR  X))) 

(BODY  (CDDR  X))) 

‘(NACRO  .(CAR  X)  (•RACROARG*) 

.IF  (NOT  (AND  (ZEROP  (CAR  PAIR)) 

(NULL  (CDR  PAIR)))) 

‘((AND  .(COND  ((ZEROP  (CAR  PAIR)) 

‘(>  (LENGTH  eNACROARC*) 

.(1*  (CDR  PAIR)))) 

((NULL  (CDR  PAIR)) 

‘ (<  (LENCTH  eNACROARC*) 

.(1*  (CAR  PAIR)))) 

(T  ‘(OR  (<  (LENCTH  eNACROARC*) 

. (!♦  (CAR  PAIR))) 

(>  (LENCTH  eNACROARC*) 

.(1*  (COR  PAIR)))))) 

(ERROR  a¥roag  sseber  of  trgs  to  ascro:  "S* 
•NACROARC*)))) 

. (DEFHACR02  (NRE VERSE  *VARLIST*)  (NRE VERSE  *VALLIST») 
•OPTIONAL-SPECIFIED-FLACS*  BODY))))) 


;;  Put  together  the  various  bisdisgs  asd  the  body. 

The  VARS  are  bouad  sequentially  siace  their  iaitisl izstioas  aay  depead 
;  oa  each  other  (ia  left-to-right  fashioa). 

(DEFUN  DEFHACR02  (VARS  VALS  FLACS  BODY) 

‘(LET*  (.NFLACS 

. NAPCAR  •’ (LANBDA  (X  Y)(LIST  X  Y))  VARS  VALS) 

(•NACROARC1*  .(IF  (CDR  BODY) 

' (PROGN  .  .BODY) 

(CAR  BODY)))) 

(IF  (CONSP  *NACR0ARC1 •) 

(RPLACB  *NACROARC*  *NACROARCl*) 

•NACROARC!  •))) 

(DEFUN  OEFNACRO-PARSE-A  (PATTERN  PATH  STATE  EPAT) 

(COND  ((NULL  PATTERN)  (CONS  0  0)) 

((ATOM  PATTERN) 

(COND  ((>  STATE  1)  (ERROR  aBsd  patters  to  DEFNACRO:  *Sa  EPAT)) 
(T  (DEFNACRO-COLLECT  PATTERN  PATH) 

(NCONS  0)))) 

((EO  (CAR  PATTERN)  ‘AOPTIONAL) 
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sua- i s-coua te  r  ass i gaaent-backua  rds) ) 

(setf  Missing-rales*  ' (eissiag-exceptioa-guard  aissiBg-internsl-gaard 
a i ss i ng-gua  rded-coaater) ) 


;;  Load  the  files  before  «e  start  for  saoother  operation, 
(coad  ((fuactionp  ’aake-a i adoa-streaa)  ()) 

(t  (load  *1  ispl  ibWastreaa.  Isp*))) 

; ;  (coad  ((fuactionp  ’dribble)  0) 

(t  (load  *1  ispl  ibWdribble.  Isp"))) 

;;;  Soae  useful  aacros  froa  COMMON  Lisp 
(DEFHACRO  WTH-OPEN-STREAN  X 
‘(LET  (.(CAR  X)) 

(UNWIND-PROTECT 
. (IF  (CDDR  X) 

* (PROCN  .CDR  X)) 

(CADR  X)) 

(CLOSE  .(CAAR  X))))) 

(DEFHACRO  WITH-OPEN-FILE  X 
’ (WITH-OPEN-STREAH  (.(CAAR  X)  (OPEN  .CDAR  X))) 

.CDR  X))) 


(e-p roust) 


Micro-PROUST  Code 


input  before  line  "a  is  executed.  The  *•  is  not  defined  when 
there  is  no  input.* 

(node-line  (or  (car  (bug-coaponent  bug))  eparse-tree*)) 
(get  (bug-goal  bug)  ‘nase-phiase))) 


;; Hissing- interna  I -guard  rule 


(defun  aissing-internal-gutrd-actioa  () 

‘ (a issing- interna  I -guard  (coapoaeat  .  . (edr  (assoc  'aaialoop: 

(ias-biadings  plan)))) 

(goal  .  .(car  *aeti ue-goal*)))) 

(dps  aissing-internal-guard  ptan-coaponeat  interna l-guard: 
action  a i ss i ng- internal -guard-act i on 
report-fun  report-a i ss i ng-  i at eras  I -gua  rd) 

(defun  report-a issing- interna l-guard  (bug) 

(foraat  t 

■You’re  aissing  a  sentinel  guard  in  the  loop  beginning  at  line  "a.  When 
your  prograa  reads  the  sentinel,  it  processes  it  as  if  it  aere  data.* 
(node-line  (or  (car  (bug-coaponent  bug))  eparsa-tree*)))) 


; .Hissing-guarded-counter  rule 


(defun  aissing-guarded-couater-actioa  () 

* (aissing-guarded-counter  (coapoaeat  .  . (edr  (assoc  ‘iapat: 

(ins-bladings  plan)))))) 

(dps  aissing-gaarded-couater  plaa-coaponest  process: 
plea  bad- input- loop-guard 
action  aissing-gaarded-couater-actioa 
report-f u a  report-a i ss i ng-gaa rded-coaater) 

(defun  report-sissing-guarded-counter  (bug) 

(foraat  t 

■You're  aissing  a  sentinel  guard.  If  a  sentiael  value  is  input  iaaediately 
fol loving  a  negative  valve  at  line  *a,  your  prograa  vill  process  it 
as  if  it  were  data  * 

(node-line  (or  (car  (bug-coaponent  bug))  eparse-tree*)))) 


; ;Riss-ieterael-gvsrd  report 


(defua  report-a iss- interna  I -guard  (bag) 

(foraat  t 

■Your  prograa  does  not  perfora  su  input  vul idatiou.*)) 

(dps  loop-iapet-val idatioa  report-fun  report-aiss-internal-guard) 


;;Rule  list 


(sutf  *aalforaud-rules*  ’ (read-is-couater  vhi le-for-i f 
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(dps  sua-is-counter  found  1  plan  runn i ng-tote I  action  sua-is-counter-action 
report-fun  report-sua-is-counter) 

(defue  report-sua-is-counter  (bag) 

(foraat  t 

•You  arc  using  a  counter  update  instead  of  a  running-total  update  at 
line  *a.  You  aust  add  the  value  of  *a  to  the  variable  "a.  not  add  1  to  it.* 
(node- line  (bug-stateaent  bug)) 

(resol ve-var-ref  ‘ne*  'sentinel-control led-loop) 

(node-naae  (car  (node-children  (bug-stateaent  bug)))))) 


; ; Assignaent-backvards  rule 


(defun  assignaent-backvards-test  () 

(and  (equal  (length  (aatch-fraae-errors  aatch-fraae))  2) 

(equal  (node-naae  (aatch-fraae-code  aatch-fraae))  ’:*) 

(equal  (length  (node-children  (aatch-fraae-code  aatch-fraae)))  2) 
(equal  (caar  (aatch-fraae-errors  aatch-fraae)) 

(cdadr  (aatch-f raae-errors  aatch-fraae))) 

(equal  (cdar  (aatch-fraae-errors  aatch-fraae)) 

(caadr  (aatch-fraae-errors  aatch-fraae))) 

(incf  explained-errors) 

(incf  expl a i ned-errors) )) 

(defun  assignaent-backaards-actioa  () 

'(assignaent-backvards  (stateaeat  .  .aatch-fraae))) 

(dps  assignaent-backvards  plan-coapoaeat  update: 
test-code  assignaent-backvards-test 
action  ass i gnaent-back va rds-act ioa 
report-fun  report-ass ignacat-backvards) 

(defun  report-ass ignaent-backvards  (bag) 

(foraat  t 

■The  assignaent  at  line  'a  is  backvards.  This  line  will  assign  to  *a; 

you  need  to  assign  to  'a.* 

(node-tine  (bug-stateaent  bug)) 

(node-naae  (car  (node-children  (bug-stateaent  bug)))) 

(node-naae  (cadr  (node-children  (bug-stateaent  bug)))))) 


; ;dissing-evception-guard-rule 


(defun  eissiag-exeeption-guard-actioa  () 

' (a issing-except ion-guard  (coaponent  .  . (cdr  (assoc  'code 

(ins-bindings  plan)))) 
(goal  .  .(cdr  (assoc  'goal 

(ins-bindings  plan)))))) 

(dps  aissing-exception-guard  plan-coaponent  exception: 
action  a i ss i ng-e xcept i on-gua rd-a ct i on 
report-fun  report-aissing-guerd-exception) 

(defun  report-aissing-guard-exception  (bug) 

(foraat  t 

■You  need  a  test  to  check  that  at  least  one  valid  data  point  has  been 
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H.3  EXAMPLE3  .PAS 

PROGRAM  NOAH  (INPUT  .OUTPUT); 


RAINFALL.  LARGEST.  SUN.  C0UNT1. 
C0UNT2.  AVERACE.  RAINYDAYS  :  REAL; 


BEGIN 

(•  INITIALIZE  VARIABLES  •) 

LARCEST  : *0; 

SUN  :*0; 

COUNT 1  =0; 

COUNT 2  :=0; 

AVERACE  *0; 

RAINYDAYS  :=0; 

(♦READ  THE  RAINFALL  AND  CHECK  FOR  ERROR  VALUES  *) 

VRITELN  (’ENTER  RAINFALL.  NHEN  YOU  ARE  FINISHED  ENTER  9999’); 

READLN; 

READ  (RAINFALL); 

WHILE  RAINFALL  <>  9999  DO 
BEGIN 

WHILE  RAINFALL  <0  DO 
BEGIN 

WRITELN  (RAINFALL  :8.’IS  NOT  A  POSSIBLE  RAINFALL.  TRY  AGAIN. ') ; 
WRITELN  CENTER  RAINFALL'); 

READLN; 

READ  (RAINFALL) 

END; 

IF  RAINFALL  >  LARCEST 
THEN 

LARCEST  :=RAINFALL; 

IF  RAINFALL  >  0 
THEN 

C0UNT2  : =C0UNT2  ♦  1; 

COUNT 1  :■  C0UNT1  ♦  1; 

SUN  :■  SUN  ♦  RAINFALL; 

READLN. 

READ  (RAINFALL) 

END; 

AVERACE  :»  SUR/C0UNT1; 

WRITELN  (COUNT!  :8.  'VALID  RAINFALLS  WERE  ENTERED.’); 

WRITELN  ('THE  AVERACE  RAINFALL  NAS'.  AVERAGE  :8.  'INCHES  PER  DAY.'); 
WRITELN  ('THE  HIGHEST  RAINFALL  NAS'.  LARGEST  :0:2.  ’INCHES.'); 

NRITELN  (’THERE  NERE*.  C0UNT2  :0;2.  'RAINYDAYS  IN  THIS  PERIOD') 

END. 
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n.4  EXAMPLE4.PAS 

PROGRAN  RAINFALL  (  INPUT. OUTPUT  ); 

VAR 

RAIN.  DAYS.  TOTALRAIN.  RAINDAYS.  HICHRAIN.  AVERAIN:  REAL: 

BEGIN 

DAYS  :«  0; 

TOTALRAIN  .«  0; 

RAINDAYS  :«  0; 

HICHRAIN  :*  0. 

REPEAT 

WRITELN  (’ENTER  RAINFALL’): 

READLN. 

READ  (RAIN): 

WHILE  RAIN  <>  9999  DO 
BECIN 

DAYS  *  DAYS  ♦  1; 

TOTALRAIN  :*  TOTALRAIN  ♦  RAIN; 

IF  RAIN  >  0  THEN 
RAINDAYS  :«  RAINDAYS  ♦  1: 

IF  RAIN  >  HICHRAIN  THEN 
HICHRAIN  :«  RAIN 
END 

UNTIL  RAIN  *  9999: 

AVERAIN  :■  TOTALRAIN  /  DAYS; 

WRITELN. 

WRITELN  (  DAYS  0:0.  'VALID  RAINFALLS  WERE  ENTERED’): 

WRITELN; 

WRITELN  (’THE  AVERAGE  RAINFALL  WAS’ .AVERAIN :0:2. ’INCHES  PER  DAY’); 
WRITELN; 

WRITELN  (’THE  HIGHEST  RAINFALL  WAS’ .HICHRAIN :0: 2, ’INCHES’) ; 
WRITELN. 

WRITELN  (’THERE  WERE’ .RAIN0AYS:O:O. ’IN  THIS  PERIOD*); 

END 
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II.S  EXAMPLES. PAS 

PROCRAN  TEST1 (INPUT.  OUTPUT); 

VAR 

SUN,N.BAX,AVE:REAL; 

COUNT. RAIHY: INTEGER; 

BECIN 
SUN :*0; 

COUNT :«0; 

RAINY  :*d; 

BAX  :«0 

VRITELNCENTER  RAINFALL’); 

READLN ; 

READ(N) ; 

WHILE  N<>9999  DO 
BEGIN 

IF  N<0  THEN 

VRITELN(N:0:2. ’  IS  NOT  A  POSSIBLE  RAINFALL.  TRY  AGAIN') 

ELSE 

BEGIN 

COUNT. =COUNT*l; 

SUB:=SUB*1; 

IF  N>0  THEN 
RAINY  =RAINY*1; 

IF  N>HAX  THEN 
N:=BAX; 

END; 

VRITELNCENTER  RAINFALL'); 

READLN; 

READ(N) 

END; 

VRITELN; 

IF  C0UNT=0  THEN 

VRITELN (COUNT :0. ’  VALID  RAINFALLS  WERE  ENTERED.') 

ELSE 

BECIN 

AVE : *SUB/COUNT ; 

VRITELN  ('THE  AVERAGE  RAINFALL  VAS  \AVE:0:2.’  INCHES  PER  DAY.'); 
VRITELN (‘THE  HICHEST  RAINFALL  HAS  \NAX.O:2.’  INCHES.'); 

VRITELN ('THERE  VERE  '. RAINY :0.'  RAINY  DAYS  IN  THIS  PERIOD.’) 
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n.»  EXAMPLEA.PAS 

PROGRAM  Aveng*  (input. output) ; 
VAR  Sue.  Count.  Neu:  INTEGER; 

A*g  REAL; 

BECIN 
Sue  ;■  0; 

Count  :*  0; 

Rend  (Nee); 

WHILE  Nee<>9999  DO 
BEGIN 

Sue  :»  Sue*Neu. 

Count  :*  Count*!: 

Reed  (Nee) 

END; 

IF  Count  »  0 

THEN  VRITELN  ('No  euenge’) 
ELSE  BEGIN 

Aug  ;»  Sue/Count: 

VRITELN  ('The  euereg*  i* 
END 

END; 


’.evg); 
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H.7  EXAMPLER  .PAS 

PROCRAB  TESTKIMPUT.  OUTPUT); 

VAR 

SUB. B. BAX. AVE: REAL; 

COURT , RAIBY : IBTECER ; 

SEC  IB 
SUN:=0; 

COUNT ;=0; 

RAINY  :*0; 

BAX  :*0: 

WRITELN (' ENTER  RAINFALL'): 

REAOLN; 

READ(N) ; 

WHILE  N<>9999  DO 
BECIN 

IF  N<0  THEN 

WRITELN(N:0:2, *  IS  NOT  A  POSSIBLE  RAINFALL.  TRY  ACAIN') 

ELSE 

BECIN 

COUNT : =COUNT*l ; 

SUB : =SUB*N ; 

IF  N>0  THEN 
RAINY :*RAINY*1; 

IF  N>BAX  THEN 
BAX : =N . 

END. 

WRITELN (’ENTER  RAINFALL1); 

READLN; 

READ(N) 

END. 

WRITELN; 

IF  COUNT-O  THEN 

WRITELN (COUNT  0.  ’  VALID  RAINFALLS  WERE  ENTERED. ’) 

ELSE 

BECIN 

AVE : “SUB/COUNT ; 

WRITELN (COUNT  0, '  VALID  RAINFALLS  WERE  ENTERED.’); 

WRITELN (’THE  AVERAGE  RAINFALL  WAS  ’.AVE:0:2.’  INCHES  PER  DAY.’); 
WRITELN (‘THE  HIGHEST  RAINFALL  WAS  '.BAX:0:2.’  INCHES.'); 

WRITELN ('THERE  WERE  ' ,RAINY:0. ’  RAINY  DAYS  IN  THIS  PERIOO.’) 
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m.  Problem  Specifications 


m.l  AVERAGE. PRB 

;;  Average  Probiea  AVERACE.prb 

Take*  froa  Ricro-Proust  Desiga  Spec  10/23/84 

;;  (goal  .  average)  vis  added  to  guard  eieeptioa  to  Bake 
;;  beg  reporting  for  aissiag-exceptioa-guard  aieer 

((sentinel-control  led- loop  (stop  .  9999)) 

(average) 

(covet  (coant  .  (*var*  covnt  average))) 

(sea  (nev  .  (*var«  nee  sentinel -control  led- loop)) 

(total  .  (*var*  sea  average))) 

(output  (val  .  (*var*  avg  average))) 

(guard-exception  (code  .  (*var*  output:  output)) 

(pred  .  (*  (*vare  count  count)  0)) 
(goal  .  average)) 

(guard-exception  (code  .  (*var*  update:  average)) 

(pred  .  (*  (*var«  count  count)  0)) 
(goal  .  average))) 


Micro-PROUST  Code 


m.2  RAINFALL.PRB 


;;  Rainfall  P rob  lea  Description  RAINFALL. prb 

;;  Taken  fro*  Nicro-P roust  Design  Spec  10/23/84 

(goal  .  x)  added  to  guard-exception  to  take  bug  reporting  nicer 
((sentinel-control led-loop  (stop  .  9999)) 

(loop-input-validation  (neu  .  (*var*  nea  sentinel-control led-loop)) 

(pred  .  (<  (*var*  neu  sentinel-control  fed-loop)  0))) 

(average) 

(count  (count  .  (*var*  count  average))) 

(output  (val  .  (*var*  avg  average))) 

(guard-exception  (code  .  (*var*  output:  output)) 

(pred  .  (*  (*var*  couat  count)  0)) 

(goat  .  average)) 

(output  (val  .  (*var*  count  count))) 

(sua  (neu  .  (*var*  neu  sentinel-control led-loop)) 

(total  .  (*var*  sua  average))) 

(guarded-count  (pred  .  (>  (*var*  neu  sentinel-control led-loop)  0))) 

(output  (val  .  (*var*  count  guarded-count))) 

(aaxiaua  (neu  .  (*var*  neu  sentinel-control led-loop))) 

(output  (val  .  (*var*  aax  aaxiaua))) 

(guard-exception  (code  .  (*vnr»  update:  average)) 

(pred  .  («  (*var*  count  count)  0)) 

(goal  .  average)) 

(guard-exception  (code  .  (*vare  output:  output)) 

(pred  .  (*  (*vare  couat  couat)  0)) 

(goal  .  aaxiaua))) 
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